Aller au contenu

Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
A propos de l'auteur
Introduction
Partie I : Conception de bases de données relationnelles
8h 33min restantes

Introduction

La cuisine simple ne peut pas être confiée à de simples cuisiniers.

—COMTESSE M ORPHIE _

Je suis toujours étonné de voir à quel point les logiciels de bases de données

ont évolué au cours des 25 dernières années. Nous sommes passés de bases

de données stockées et exécutées à partir d'ordinateurs personnels à des

bases de données partagées et centralisées à l'échelle de l'entreprise sur des

architectures client/serveur connectées au sein de réseaux locaux et étendus,

jusqu'à des applications accessibles sur des appareils personnels avec des

bases de données stockées dans le cloud.

Les systèmes de gestion de bases de données ont également évolué. Ils sont

beaucoup plus faciles à utiliser et à entretenir, ils gèrent désormais de très gros

volumes de données et ils sont aussi omniprésents que des hamburgers. Vous

utilisez tout le temps des applications créées avec eux sur votre ordinateur et

vos appareils lorsque vous travaillez, faites des achats ou recherchez des

informations sur Internet.

Les fournisseurs de logiciels de bases de données continuent d'ajouter de

nouvelles fonctionnalités et d'améliorer les ensembles d'outils de leurs

produits, permettant aux développeurs de bases de données de créer des

applications de bases de données plus puissantes et plus flexibles. Ils

améliorent également constamment la facilité d'utilisation du logiciel,

permettant ainsi à de nombreuses personnes de créer leurs propres

applications de base de données. Les logiciels de bases de données

d'aujourd'hui simplifient considérablement le processus de création de

structures de bases de données efficaces et d'interfaces utilisateur intuitives.

La plupart des programmes fournissent des exemples de structures de bases

de données que vous pouvez copier et modifier en fonction de vos besoins

spécifiques. Bien que vous puissiez penser au départ qu'il serait très

avantageux d'utiliser ces exemples de structures comme base pour une

nouvelle base de données, vous devriez vous arrêter etreconsidérez cette

décision un instant. Pourquoi? Parce que vous pourriez facilement et

involontairement créer une conception inappropriée, inefficace et

incomplète. Vous finirez alors par rencontrer des problèmes dans ce que vous

considérez comme une conception de base de données fiable. Cela soulève

bien sûr la question : « Quels types de problèmes pourrais-je rencontrer ? »

La plupart des problèmes qui apparaissent dans une base de données se

répartissent en deux catégories : les problèmes d'utilisation des applications et

les problèmes de données . Les problèmes d'application incluent des éléments

tels que des formulaires de saisie/modification de données problématiques, des

menus et des barres d'outils déroutants, des boîtes de dialogue déroutantes et

des séquences de tâches fastidieuses. Ces problèmes surviennent

généralement lorsque le développeur de base de données est inexpérimenté,

n'est pas familier avec une bonne méthodologie de conception d'applications,

connaît trop peu le logiciel qu'il utilise pour implémenter la base de données ou

a une compréhension insuffisante des données avec lesquelles il travaille. Les

problèmes de cette nature sont courants et importants à résoudre, mais ils

dépassent la portée de ce travail.

Note

Un bon moyen de résoudre bon nombre de vos problèmes d'application

consiste à acheter et à étudier des livres de « développeurs » tiers qui couvrent

le logiciel que vous utilisez. Ces livres traitent des problèmes de conception

d'applications, des techniques de programmation avancées et de divers trucs

et astuces que vous pouvez utiliser pour améliorer et améliorer une

application. Armé de ces nouvelles compétences, vous pouvez réorganiser et

affiner l’application de base de données afin qu’elle fonctionne correctement,

de manière fluide et efficace.

Les problèmes de données, en revanche, incluent des éléments tels que des

données manquantes, des données incorrectes, des données incompatibles et

des informations inexactes. Une mauvaise conception de base de données est

généralement à l’origine de ces types de problèmes. Une base de données ne

répondra pas aux besoins d'information d'une organisation si elle n'est pas

correctement structurée. Même si une mauvaise conception est généralement

générée par un développeur de bases de données qui ne connaît pas les bons

principes de conception de bases de données, elle ne devrait pas

nécessairement avoir un impact négatif surle développeur. De nombreuses

personnes, y compris des programmeurs et des développeurs de bases de

données expérimentés, n'ont reçu que peu ou pas de formation sur une

quelconque forme de méthodologie de conception de bases de

données. Beaucoup ignorent qu’il existe des méthodologies de conception. Les

problèmes de données et une mauvaise conception sont les problèmes que ce

travail abordera.

Quoi de neuf dans la quatrième édition

J'ai révisé cette édition pour améliorer la lisibilité, mettre à jour ou étendre les

sujets existants, ajouter du nouveau contenu et améliorer sa valeur

pédagogique. Voici une liste des changements que vous trouverez dans cette

édition.

• Des parties du texte ont été réécrites pour améliorer la clarté et la

compréhension du lecteur.

• Les chiffres ont été mis à jour pour améliorer leur pertinence, le cas

échéant.

• Il y a maintenant une nouvelle section « Exemple » à la fin des chapitres

5 à 13 .
• Le chapitre 1 a été révisé, supprimant le contenu qui n'est plus important et

ajoutant une section « Quelle est la prochaine étape ? » section concernant

ce que je considère comme l'état actuel et l'avenir de la base de données

relationnelle.

• Le chapitre 5 contient une nouvelle note concernant le COVID-19 et son

impact sur la réalisation des entretiens pour le processus de conception.

• La discussion du chapitre 5 sur les entretiens et les lignes directrices pour

les intervieweurs ont toutes deux été légèrement révisées pour tenir compte

de la popularité et de l'acceptation croissantes des réunions en ligne et des

scénarios de travail à domicile (WFH).

• L' exemple de boîte de dialogue d' entretien du chapitre 7 a été mis à jour à

la suite des modifications apportées aux lignes directrices pour les

enquêteurs au chapitre 5 .

• Le formulaire Spécifications de champ a été légèrement rationalisé et le

formulaire Règles métier a été ajusté de manière appropriée pour le

synchroniser avec les modifications apportées au formulaire Spécifications

de champ.

• Les processus Technique d’identification du sujet et Technique

d’identification des caractéristiques ont également été ajustés pour tenir

compte des scénarios de réunion en ligne.

• Les « Questions de révision » de fin de chapitre ont été mises à jour pour

refléter les nouvelles questions, et des modifications ont été apportées aux

questions existantes.

• La section « Lectures recommandées » comprend les dernières éditions des

livres.
Qui devrait lire ce livre

Aucune expérience préalable en conception de bases de données n’est

nécessaire pour lire ce livre. La raison pour laquelle vous avez ce livre entre vos

mains est d’apprendre à concevoir correctement une base de données. Si vous

débutez dans la gestion de bases de données et envisagez de développer vos

propres bases de données, ce livre vous sera très précieux. Il est préférable

d’apprendre à créer correctement une base de données dès le début plutôt que

d’apprendre par essais et erreurs. Croyez-moi, cette dernière méthode prend

beaucoup plus de temps.

Si vous appartenez à la catégorie des personnes qui travaillent avec des

programmes de bases de données depuis un certain temps et qui sont prêtes à

commencer à développer de nouvelles bases de données pour votre entreprise

ou votre entreprise, vous devriez lire ce livre. Vous avez probablement une

bonne idée de ce à quoi devrait ressembler une bonne structure de base de

données, mais vous ne savez pas vraiment comment les développeurs de

bases de données parviennent à une conception efficace. Peut-être êtes-vous

un programmeur qui a créé un certain nombre de bases de données en suivant

quelques directives de base, mais vous avez toujours fini par écrire beaucoup

de code pour que la base de données fonctionne correctement. Si tel est le cas,

ce livre est aussi pour vous.

La lecture de ce livre est également une bonne idée même si vous avez déjà

une certaine expérience en conception de bases de données. Peut-être avez-

vous appris une méthodologie de conception à l'université ou assisté à un

cours de base de données traitant de la conception, mais votre mémoire est

vague sur certains détails, ou vous n'avez tout simplement pas complètement

compris certaines parties du processus de conception. Les points avec lesquels

vous avez rencontré des difficultés deviendront enfin clairs une fois que vous

aurez appris et compris le processus de conception présenté dans ce livre.

Ce livre convient également à ceux d'entre vous qui sont des développeurs et

programmeurs de bases de données expérimentés. Même si vous connaissez

peut-être déjà de nombreux aspects du processus de conception présentés

dans ce livre, vous trouverez probablement certains éléments que vous n'avez

jamais rencontrés ou pris en compte auparavant. Vous pouvez même trouver

de nouvelles idées sur la façon de concevoir vos bases de données en

examinant le contenu de ce livre, car de nombreux processus de conception

qui vous sont familiers sont présentés sous un point de vue différent. Mais

n’oubliez pas que si vous êtes ce type de personne, il ne s’agira pour vous que

d’un simple aperçu des concepts généraux d’une bonne conception de base de

données. Aucune normalisation. Pas de jargon technique. Aucun langage de

programmation ni références de code. Juste un bon aperçu de ce à quoi

ressemblent des structures de données solides et des raisons qui motivent la

prise de décisions structurelles judicieuses et judicieuses.

Le but de ce livre

En termes généraux, le processus global de développement d’une base de

données comporte trois phases.

1. Conception logique : la première phase consiste à déterminer et définir les

tables et leurs champs, à établir les clés primaires et étrangères, à établir

les relations entre les tables, ainsi qu'à déterminer et établir les différents

niveaux d'intégrité des données.

2. Implémentation physique : la deuxième phase consiste à créer les tables, à

établir les champs clés et les relations entre les tables et à utiliser les outils

appropriés pour mettre en œuvre les différents niveaux d'intégrité des

données.

3. Développement d'applications : La troisième phase consiste à créer une

application permettant à un seul utilisateur ou à un groupe d'utilisateurs

d'interagir avec les données stockées dans la base de données. La phase de

développement de l'application elle-même peut être divisée en processus

distincts, tels que la détermination des tâches de l'utilisateur final et de

leurs séquences appropriées, la détermination des informations requises

pour la sortie du rapport et la création d'un système de menus pour

naviguer dans l'application.

Vous devez toujours commencer par la conception logique et l’exécuter aussi

complètement que possible. Après avoir créé une structure solide, vous pouvez

l'implémenter dans n'importe quel logiciel de base de données de votre

choix. Au début de la phase de mise en œuvre, vous constaterez peut-être que

vous devrez modifier la structure de la base de données en fonction des

avantages et des inconvénients ou des forces et des faiblesses du logiciel de

base de données que vous avez choisi. Vous pouvez même décider d'apporter

des modifications structurelles pour améliorer les performances de traitement

des données. Effectuer d'abord la conception logique garantit que vous prenez

des décisions conscientes, méthodiques, claires et éclairées concernant la

structure de votre base de données. En conséquence, vous contribuez à

minimiser le nombre potentiel de modifications structurelles supplémentaires

que vous pourriez avoir besoin d'effectuer pendant les phases de mise en

œuvre physique et de développement d'applications.

Ce livre traite uniquement de la phase de conception logique du processus de

développement global, et son objectif principal est d'expliquer le processus de

conception de bases de données relationnelles sans utiliser les méthodologies

orthodoxes avancées que l'on trouve dans une écrasante majorité des livres de

conception de bases de données. J'ai pris soin d'éviter les complexités de ces

méthodologies en présentant une approche relativement simple et pleine de

bon sens du processus de conception. J'utilise également un système de

données simple et directméthode de modélisation en complément de cette

approche et présenter l'ensemble du processus le plus clairement possible et

avec un minimum de jargon technique.

De nombreux livres sur la conception de bases de données sur le marché

incluent des chapitres sur la mise en œuvre de la base de données dans un

produit de base de données spécifique, et certains livres semblent même

fusionner les phases de conception et de mise en œuvre. (Je n'ai jamais été

particulièrement d'accord avec l'idée de combiner ces phases, et j'ai toujours

soutenu qu'un développeur de bases de données devait effectuer les phases de

conception logique et de mise en œuvre séparément pour garantir une

concentration, une efficacité et une efficience maximales.) Le principal

inconvénient que j'ai Ce que j'ai rencontré avec ce type de livres, c'est qu'un

lecteur peut avoir des difficultés à obtenir des informations utiles ou

pertinentes dans les chapitres de mise en œuvre s'il ne travaille pas avec le

logiciel de base de données ou le langage de programmation particulier

incorporé dans le livre. C'est pour cette raison que j'ai décidé d'écrire un livre

qui se concentre strictement sur la conception logique de la base de données.

Ce livre devrait être plus facile à lire que d’autres livres que vous avez pu

rencontrer sur le sujet. La plupart des ouvrages sur la conception de bases de

données disponibles sur le marché sont très techniques et peuvent être

difficiles à assimiler. Je pense que la plupart de ces livres peuvent être

déroutants et accablants si vous n'êtes pas un spécialiste en informatique, un

théoricien des bases de données ou un développeur de bases de données

expérimenté. Les principes de conception que vous apprendrez dans ces pages

sont faciles à comprendre et à retenir, et les exemples sont suffisamment

courants et génériques pour être pertinents dans une grande variété de

situations.

La plupart des gens que j'ai rencontrés lors de mes voyages à travers le pays

m'ont dit qu'ils voulaient simplement apprendre à créer une structure de base

de données solide sans avoir à se renseigner sur les formes normales ou les

théories mathématiques avancées. De nombreuses personnes ne s'inquiètent

pas autant de la mise en œuvre d'une structure dans un logiciel de base de

données spécifique que d'apprendre à optimiser leurs structures de données et

à imposer l'intégrité des données. Dans ce livre, vous apprendrez à créer une

base de données efficacestructures, comment imposer plusieurs niveaux

d'intégrité des données, ainsi que comment relier les tableaux entre eux pour

obtenir des informations d'un nombre presque infini de façons. Ne t'inquiète

pas; ce n’est pas une tâche aussi difficile qu’on pourrait le penser. Vous serez

en mesure d'accomplir tout cela en comprenant quelques termes clés et en

apprenant et en utilisant un ensemble spécifique de techniques et de concepts

de bon sens.
Vous apprendrez également à analyser et à exploiter une base de données

existante, à déterminer les besoins en informations, ainsi qu'à déterminer et

mettre en œuvre des règles métier. Ces sujets sont importants car beaucoup

d'entre vous hériteront probablement d'anciennes bases de données qu'il vous

faudra réorganiser en utilisant ce que vous apprendrez en lisant ce livre. Ils

seront également tout aussi importants lorsque vous créerez une nouvelle base

de données à partir de zéro.

Lorsque vous aurez fini de lire ce livre, vous disposerez des connaissances et

des outils nécessaires pour créer une bonne structure de base de données

relationnelle. Je suis convaincu que toute cette approche fonctionnera pour une

majorité de développeurs et pour les bases de données qu'ils doivent créer.

Comment lire ce livre

Je vous recommande fortement de lire ce livre dans l'ordre du début à la fin,

que vous soyez novice ou professionnel. De cette façon, vous garderez tout

dans son contexte et éviterez la confusion qui vient généralement du fait de ne

pas être en mesure d'avoir une « vision d'ensemble » en premier. C'est

également une bonne idée d'apprendre le processus dans son ensemble avant

de commencer à vous concentrer sur une seule partie.

Si vous lisez ce livre pour rafraîchir vos compétences en conception, vous

pouvez lire uniquement les sections qui vous intéressent. Dans la mesure du

possible, j'ai essayé d'écrire chaque chapitre de manière à ce qu'il puisse être

autonome ; néanmoins, je vous recommande quand même de parcourir chaque

chapitre pour vous assurer de ne manquer aucune nouvelle idée ou point sur le

design que vous n'avez peut-être pas envisagé jusqu'à présent.

Comment ce livre est organisé

Ce qui suit est un bref aperçu de ce que vous trouverez dans chaque partie et

chaque chapitre.

Partie I : Conception de bases de données relationnelles

Cette section fournit une introduction aux bases de données, l'idée de la

conception de bases de données et une partie de la terminologie que vous

devrez connaître pour apprendre et comprendre le processus de conception

présenté dans ce livre.

Le chapitre 1 , « La base de données relationnelle », fournit une brève

discussion des types de bases de données que vous rencontrerez, des modèles

de bases de données courants et un bref historique de la base de données

relationnelle.

Le chapitre 2 , « Objectifs de conception », explore les raisons pour lesquelles

vous devriez vous préoccuper de la conception, souligne les objectifs et les

avantages d'une bonne conception et fournit une brève introduction à la

normalisation et aux formes normales.

Le chapitre 3 , « Terminologie », couvre les termes que vous devez connaître

pour apprendre et comprendre la méthodologie de conception présentée dans

ce livre.
Partie II : Le processus de conception

Chaque aspect du processus de conception de base de données est abordé en

détail dans la partie II , notamment l'établissement de structures de tables,

l'attribution de clés primaires, la définition de spécifications de champs,

l'établissement de relations entre tables, la configuration de vues et

l'établissement de divers niveaux d'intégrité des données.

Le chapitre 4 , « Aperçu conceptuel », fournit un aperçu du processus de

conception, vous montrant comment les différents composants du processus

s'articulent.

Le chapitre 5 , « Démarrage du processus », explique comment définir un

énoncé de mission et des objectifs de mission pour la base de données, qui

vous fournissent tous deux une orientation initiale pour la création de votre

base de données.

Le chapitre 6 , « Analyse de la base de données actuelle », couvre les

problèmes concernant la base de données existante. Nous examinons les

raisons d'analyser la base de données actuelle, comment examiner les

méthodes actuelles de collecte et de présentation des données, pourquoi et

comment mener des entretiens avec les utilisateurs et la direction, et comment

compiler les premières listes de champs.

Le chapitre 7 , « Établissement des structures de table », couvre des sujets

tels que la détermination et la définition des sujets que la base de données doit

suivre, l'association des champs aux tables et l'affinement des structures de

table.
Le chapitre 8 , « Clés », couvre le concept de clés et leur importance dans le

processus de conception, ainsi que la manière de définir les clés candidates et

primaires pour chaque table.

Le chapitre 9 , « Spécifications des champs », aborde un sujet qu'un certain

nombre de développeurs de bases de données ont tendance à minimiser. En

plus d'indiquer comment chaque champ est créé, les spécifications de champ

déterminent la nature même des valeurs qu'un champ contient. Les sujets de

ce chapitre incluent l'importance des spécifications de champ, les types de

caractéristiques de spécification et la manière de définir des spécifications pour

chaque champ de la base de données.

Le chapitre 10 , « Relations entre tables », explique l'importance des relations

entre tables, les types de relations, l'établissement de relations et

l'établissement des caractéristiques des relations.

Le chapitre 11 , « Règles métier », couvre les types de règles métier, la

détermination et l'établissement de règles métier et l'utilisation des tables de

validation. Les règles métier sont très importantes dans toute base de données

car elles fournissent un niveau distinct d’intégrité des données.

Le chapitre 12 , « Vues », examine le concept de vues et pourquoi elles sont

importantes, les types de vues et comment déterminer et configurer les vues.

Le chapitre 13 , « Examen de l'intégrité des données », passe en revue

chaque niveau d'intégrité défini et discuté dans les chapitres précédents. Ici,

vous apprenez que revoir la conception finale de la structure de la base de

données est une bonne idée pour vous assurer que vous avez imposé l'intégrité

des données aussi complètement que possible.

Partie III : Autres problèmes de conception de bases de données

Cette section traite de sujets tels que éviter une mauvaise conception et

contourner les règles énoncées dans le processus de conception.

Le chapitre 14 , « Mauvaise conception : ce qu'il ne faut pas faire », couvre

les types de conceptions que vous devriez éviter, telles qu'une conception de

fichier plat et une conception de feuille de calcul.

Le chapitre 15 , « Enfreindre ou enfreindre les règles », aborde les rares cas

dans lesquels il peut être nécessaire de s'écarter des techniques et des

concepts du processus de conception. Ce chapitre vous indique quand vous

devriez envisager de contourner les règles, ainsi que comment vous devez le

faire.

Partie IV : Annexes

Ces annexes fournissent des informations qui, à mon avis, vous seraient utiles

lorsque vous en apprendrez davantage sur le processus de conception de base

de données et lorsque vous travaillerez au développement de votre base de

données.

L'Annexe A , « Réponses aux questions de révision », contient les réponses à

toutes les questions de révision des chapitres 1 à 12 .

L'Annexe B , « Schéma du processus de conception de base de données »,

fournit un diagramme qui cartographie l'ensemble du processus de conception

de base de données.

L'Annexe C , « Directives de conception », fournit une référence simple aux

différents ensembles de directives de conception qui apparaissent tout au long

du livre.
L'annexe D , « Formulaires de documentation », fournit des copies vierges des

feuilles Spécifications de champ, Spécifications de règle métier et

Spécifications de vue, que vous pouvez copier et utiliser sur vos projets de

base de données.

L'Annexe E , « Symboles des diagrammes de conception de bases de

données », contient une référence rapide et simple aux symboles des

diagrammes utilisés tout au long du livre.

L'Annexe F , « Exemples de conceptions », contient des exemples de

conceptions de bases de données qui peuvent servir de base à des idées de

bases de données que vous souhaiterez ou devrez créer.

L'annexe G , « Sur la normalisation », fournit une discussion sur la façon dont

j'ai intégré la normalisation dans ma méthodologie de conception.

L'Annexe H , « Lectures recommandées », fournit une liste de livres que vous

devriez lire si vous souhaitez poursuivre une étude approfondie de la

technologie des bases de données.

Le glossaire contient des définitions concises de divers mots et expressions

utilisés tout au long du livre.

IMPORTANT : LIRE CETTE SECTION !

Un mot sur les exemples et les techniques de ce livre

Vous remarquerez que ce livre contient une grande variété d’exemples. Je me

suis assuré qu'ils sont aussi génériques et pertinents que possible. Cependant,

vous remarquerez peut-être que plusieurs exemples sont plutôt simplifiés,

incomplets ou parfois même incorrects. Croyez-le ou non, je les ai créés de

cette façon exprès.

J'ai créé quelques exemples avec des erreurs afin de pouvoir illustrer des

concepts et des techniques spécifiques. Sans ces exemples, vous ne verriez

pas comment les concepts ou les techniques sont utilisés, ni comment

lesrésultats que vous devriez attendre de leur utilisation. D’autres exemples

sont simples car, encore une fois, l’accent est mis sur la technique ou le

concept et non sur l’exemple lui-même. Par exemple, vous pouvez concevoir

une base de données de suivi des commandes de plusieurs

manières. Cependant, la structure de l'exemple de base de données de suivi

des commandes que j'utilise dans ce livre est simple car l'accent est

spécifiquement mis sur le processus de conception, et non sur la création d'un

système de base de données de suivi des commandes élaboré.

Donc, ce que j'essaie vraiment de souligner ici, c'est ceci :

Concentrez-vous sur le concept ou la technique et les résultats escomptés, et

non sur l'exemple utilisé pour l'illustrer.

Mon approche de l'apprentissage

Voici mon approche pour apprendre le processus de conception (ou à peu près

n'importe quoi d'autre, d'ailleurs) que j'ai trouvée très utile dans mes cours de

conception de bases de données.

Considérez toutes les techniques utilisées dans le processus de conception

comme un ensemble d'outils ; chaque outil (ou technique) est utilisé dans un

but précis. L'idée ici est qu'après avoir appris comment un outil est utilisé de

manière générique, vous pouvez ensuite utiliser cet outil dans un certain

nombre de situations. La raison pour laquelle vous pouvez procéder ainsi

est que vous utilisez l’outil de la même manière dans chaque situation.
Prenez une clé à molette, par exemple. De manière générale, vous utilisez une

clé à molette pour serrer et desserrer un écrou sur un boulon. Vous ouvrez ou

fermez la mâchoire de la clé pour installer un boulon donné en utilisant la vis

de réglage située sur la tête de la clé. Maintenant que vous savez clairement

comment l'utiliser, essayez de l'utiliser sur quelques boulons. Essayez-le sur les

pieds d'une chaise d'extérieur, sur le couvercle de la courroie de ventilateur

d'un moteur, sur le panneau latéral d'une unité de refroidissement extérieure

ou sur les plaques de charnière d'un portail en fer. Avez-vous remarqué que

quel que soit l'endroit où vous rencontrez un écrou et un boulon, vous pouvez

toujours serrer et desserrer l'écrou en utilisant la clé Crescent de la même

manière ?

Les outils utilisés pour concevoir une base de données

fonctionnent exactement de la même manière. Une fois que vous aurez

compris comment un outil est utilisé de manière générique, il fonctionnera de

la même manière quelles que soient les circonstances dans lesquelles il est

utilisé. Par exemple, considérons l'outil (ou la technique) permettant de

décomposer une valeur de champ. Supposons que vous ayez un seul champ

Adresse dans une table CLIENTS qui contient l'adresse postale, la ville, l'état et

le code postal d'un client donné. Vous aurez du mal à utiliser ce champ dans

votre base de données car il contient plusieurs éléments de données ; vous

aurez certainement du mal à récupérer des informations sur une ville

particulière ou à trier les informations par code postal spécifique.

La solution à ce dilemme apparent consiste à décomposer le champ Adresse en

champs plus petits. Pour ce faire, identifiez les éléments distincts qui

composent la valeur du champ, puis traitez chaque élément comme son propre

champ distinct. C'est tout ce qu'on peut en dire! Ce processus constitue un «

outil » que vous pouvez désormais utiliser sur n'importe quel champ contenant

une valeur composée de deux ou plusieurs éléments de données distincts,

comme ces exemples de champs. Le tableau suivant montre les résultats du

processus de décomposition.

Nom du champ
Exemple de valeur Nouveaux noms de champs
actuel

7402, promenade Kingman, Adresse postale, ville, état, code

Adresse
Seattle, WA 98012 postal

Indicatif régional, numéro de

Téléphone (206) 555-5555
téléphone

Nom Mike Hernández Prénom nom de famille

Département, catégorie, numéro

Code Employé ITDEV0516
d'identification

Note

Vous en apprendrez davantage sur la décomposition des valeurs de champ

au chapitre 7 , « Établir des structures de table ».

Vous pouvez utiliser de la même manière toutes les techniques (« outils ») qui

font partie du processus de conception présenté dans ce livre. tu

pourrasconcevez une structure de base de données solide en utilisant ces

techniques, quel que soit le type de base de données que vous devez

créer. N'oubliez pas ceci :

Concentrez-vous sur le concept ou la technique présentée et sur les résultats

escomptés, et non sur l'exemple utilisé pour l'illustrer.

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
Partie I : Conception de bases de données relationnelles
1. La base de données relationnelle
2. Objectifs de conception
8h 33min restantes

La base de données relationnelle

Un poisson doit nager trois fois : dans l'eau, dans le beurre et dans le vin.

—PROVERBE POLONAIS

Sujets abordés dans ce chapitre

Qu'est-ce qu'une base de données ?

La base de données relationnelle

Et après?

Résumé

Questions de révision
La base de données relationnelle existe depuis 50 ans au moment d'écrire ces

lignes. Oui, c'est vrai : 50 ans ! Il s'agit toujours d'une industrie

multimilliardaire, elle reste le type de base de données le plus largement

utilisé, a résisté aux changements du monde des bases de données, a résisté à

l'épreuve du temps et constitue une partie essentielle de notre vie

quotidienne. Il est très probable que vous utilisiez une base de données

relationnelle chaque fois que vous achetez des biens en ligne ou dans un

magasin local, planifiez un voyage en ligne ou avec votre agent de voyages,

consultez des livres à la bibliothèque ou commandez de la nourriture à l'aide

d'une application sur votre appareil mobile. .

Qu'est-ce qu'une base de données ?

Qu'est-ce qu'une base de données ? Comme vous le savez probablement, une

base de données est une collection organisée de données utilisée dans le but

de modéliser un certain type d'organisation ou de processus

organisationnel. Peu importe que vous utilisiez des feuilles de calcul ou un

programme d'application de base de données sur le serveur.ordinateur pour

collecter et stocker les données. Tant que vous collectez des données de

manière organisée dans un but spécifique, vous disposez d’une base de

données. Dans le reste de cette discussion, nous supposerons que vous utilisez

un programme d'application pour collecter et conserver vos données.

Les deux types de bases de données dans la gestion de bases de données

sont les bases de données opérationnelles et les bases de données

analytiques .
Les bases de données opérationnelles constituent l’épine dorsale de

nombreuses entreprises, organisations et institutions à travers le monde. Ce

type de base de données est principalement utilisé dans les scénarios de

traitement des transactions en ligne (OLTP) ; c'est-à-dire dans les situations où

il est nécessaire de collecter, de modifier et de conserver des données

quotidiennement. Le type de données stockées dans une base de données

opérationnelle est dynamique , ce qui signifie qu'elles changent constamment

et reflètent toujours des informations à jour. Des organisations telles que des

magasins de détail, des entreprises manufacturières, des hôpitaux, des

cliniques et des maisons d'édition utilisent des bases de données

opérationnelles car leurs données sont en constante évolution.

En revanche, les bases de données analytiques sont principalement utilisées

dans les scénarios de traitement analytique en ligne (OLAP), où il est

nécessaire de stocker et de suivre des données historiques et temporelles. Une

base de données analytique est un atout précieux lorsqu'il est nécessaire de

suivre les tendances, de visualiser des données statistiques sur une longue

période et de faire des projections commerciales tactiques ou stratégiques. Ce

type de base de données stocke des données statiques , ce qui signifie que les

données ne sont jamais (ou très rarement) modifiées. Les informations glanées

à partir d'une base de données analytique reflètent un instantané instantané

des données. Les laboratoires chimiques, les sociétés géologiques et les

sociétés d'analyse marketing sont des exemples d'organisations qui utilisent

des bases de données analytiques.

Les bases de données analytiques utilisent souvent les données des bases de

données opérationnelles comme source de données principale, il peut donc y

avoir un certain degré d'association entre elles ; néanmoins, les bases de

données opérationnelles et analytiques répondent à des types de besoins

informatiques très spécifiques et la création de leurs structures nécessite des

méthodologies de conception radicalement différentes. Ce livrese concentre

sur la conception d’une base de données opérationnelle car il s’agit encore

aujourd’hui du type de base de données le plus utilisé dans le monde.

La base de données relationnelle

La base de données relationnelle a été conçue en 1969 et reste aujourd’hui l’un

des modèles de base de données les plus utilisés dans la gestion de bases de

données. Le père du modèle relationnel, le Dr Edgar F. Codd, était un chercheur

scientifique chez IBM à la fin des années 1960 et cherchait à cette époque de

nouvelles façons de gérer de grandes quantités de données. Son insatisfaction

à l'égard des modèles et des produits de bases de données de l'époque l'a

amené à réfléchir à des moyens d'appliquer les disciplines et les structures

mathématiques pour résoudre la myriade de problèmes qu'il avait

rencontrés. Étant mathématicien de profession, il croyait fermement qu'il

pouvait appliquer des branches spécifiques des mathématiques pour résoudre

des problèmes tels que la redondance des données, la faible intégrité des

données et la dépendance excessive de la structure d'une base de données à

l'égard de sa mise en œuvre physique.

Le Dr Codd a officiellement présenté son nouveau modèle relationnel dans un

ouvrage historique intitulé « Un modèle relationnel de données pour les

grandes banques de données partagées » 1 en juin 1970. Il a basé son

nouveau modèle sur deux branches des mathématiques : la théorie des

ensembles et la logique des prédicats de premier ordre. . En effet, le nom du

modèle lui-même est dérivé du terme relation , qui fait partie de la théorie des

ensembles. (Une idée fausse largement répandue est que le modèle relationnel

tire son nom du fait que les tables d'une base de données relationnelle peuvent

être liées les unes aux autres.)

1. Edgar F. Codd, « A Relational Model of Data for Large Shared Databanks

», Communications de l'ACM , juin 1970, 377-87.

Une base de données relationnelle stocke les données dans des relations que

l'utilisateur perçoit comme des tables. Chaque relation est composée

de tuples , ou enregistrements, et d'attributs , ou champs. (J'utiliserai les

termes tables , enregistrements et champs dans le reste du livre.) L'ordre

physique des enregistrements ouLes champs d'une table sont totalement

insignifiants et chaque enregistrement de la table est identifié par un champ

qui contient une valeur unique. Ce sont les deux caractéristiques d’une base de

données relationnelle qui permettent aux données d’exister indépendamment

de la manière dont elles sont physiquement stockées dans l’ordinateur. En tant

que tel, un utilisateur n'est pas obligé de connaître l'emplacement physique

d'un enregistrement afin de récupérer ses données.

Le modèle relationnel catégorise les relations en un-à-un , un-à-

plusieurs et plusieurs-à-plusieurs . (Ces relations sont traitées en détail

au chapitre 10 , « Relations entre tables ».) Une relation entre une paire de

tables est établie implicitement par la correspondance des valeurs d'un champ

partagé. Dans la figure 1.1 , par exemple, les tables CLIENTS et AGENTS

partagent une relation un-à-plusieurs et sont liées via un champ AGENT ID ; un

agent spécifique est associé à un ou plusieurs clients via un ID AGENT

correspondant. De même, les tables ENTERTAINERS et ENGAGEMENTS

partagent une relation un-à-plusieurs et sont liées via un ENTERTAINER ID ; un

artiste de la table ENTERTAINERS peut être associé à un ou plusieurs

engagements dans la table ENGAGEMENTS via des ID ENTERTAINER

correspondants.

Tant qu'un utilisateur est familier avec les relations entre les tables de la base

de données, il peut accéder aux données d'un nombre presque illimité de

façons. Il peut accéder aux données de tables directement liées et de tables

indirectement liées. Considérons l'ensemble des tableaux de la figure 1.1 . Bien

que la table CLIENTS soit indirectement liée à la table ENTERTAINERS,

l'utilisateur peut produire une liste de clients et des artistes qui ont joué pour

eux. (Bien sûr, cela dépend vraiment de la façon dont les tableaux sont

réellement structurés, mais je m'éloigne du sujet. Cet exemple sert notre

objectif pour l'instant.) Il peut le faire facilement car CLIENTS est directement

lié aux ENGAGEMENTS et ENGAGEMENTS est directement lié aux ANIMATEURS.

Figure 1.1 Exemples de tables associées dans une base de données
relationnelle.

Récupération des données

Vous récupérez des données dans une base de données relationnelle à

l'aide du langage de requête structuré (SQL). SQL est le langage standard

utilisé pour créer, modifier, maintenir et interroger des bases de données

relationnelles. La figure 1.2 montre un exempleInstruction de requête SQL que

vous pouvez utiliser pour produire une liste de tous les clients de la ville d'El

Paso.

Figure 1.2 Un exemple d'instruction de requête SQL.

Les trois composants d'une requête SQL de base sont l'instruction SELECT…

FROM, la clause WHERE et la clause ORDER BY. Vous utilisez la clause SELECT

pour indiquer les champs que vous souhaitez voir dans la requête et la clause

FROM pour indiquer la ou les tables auxquelles appartiennent les champs. Vous

pouvez filtrer les enregistrements renvoyés par la requête en imposant des

critères sur un ou plusieurs champs avec la clause WHERE, puis trier les

résultats par ordre croissant ou décroissant avec la clause ORDER BY.

La plupart des principaux logiciels de bases de données relationnelles actuels

intègrent diverses formes d'implémentations SQL, allant des fenêtres dans

lesquelles les utilisateurs peuvent saisir manuellement des instructions SQL «

brutes » aux outils permettant aux utilisateurs de créer des requêtes à l'aide de

générateurs de requêtes et de formulaires de requête. Par exemple, un

utilisateur travaillant avec R:BASE de R:BASE Technologies peut choisir de créer

et d'exécuter des instructions de requête SQL directement à partir d'une ligne

de commande d'invite « R> », tandis qu'une personne utilisant Microsoft SQL

Server peut trouver plus facile et plus rapide de créer des requêtes complexes.

en utilisant la fenêtre SQL « Query Designer » de SQL Server. Quelle que soit la

manière dont les requêtes sont créées, l'utilisateur peut les enregistrer pour

une utilisation ultérieure.

Il n’est pas toujours nécessaire de connaître SQL pour travailler avec une base

de données. Si votre logiciel de base de données fournit un générateur de

requêtes ou si vous utilisez une application personnalisée pour travailler avec

les données de votre base de données, vous n'aurez jamais besoin d'écrire une

seule instruction SQL. Cependant, acquérir une compréhension de base de SQL

est une bonne idée. Cela aidera ceux d'entre vous qui utilisent des outils de

création de requêtes à comprendre et à résoudre les requêtes que vous créez

avec ces outils, et ce sera certainement à votre avantage si vous devez

travailler avec des logiciels de base de données haut de gamme, tels qu'Oracle

et Microsoft SQL. Serveur.

Note
Bien qu'une discussion détaillée de SQL dépasse le cadre de ce livre, vous

devez comprendre que SQL est un langage directement lié au modèle de base

de données relationnelle. Si vous avez le désir ou le besoin d'étudier SQL, vous

pouvez commencer par lire SQL Queries for Mere Mortals, 4e édition , puis

passer à l'un des autres livres SQL figurant sur ma liste de lectures

recommandées à l' annexe H.

Avantages d'une base de données relationnelle

La base de données relationnelle offre un certain nombre d'avantages, tels que

les suivants :

• Intégrité multiniveau intégrée : l'intégrité des données est intégrée à la base

de données au niveau du terrain pour garantir l'exactitude des données ; au

niveau de la table pour garantir que les enregistrements ne sont pas

dupliqués et pour détecter les valeurs de clé primaire manquantes ; au

niveau de la relation pour garantir que la relation entre une paire de tables

est valide ; et au niveau de l'entreprise pour garantir que les données sont

exactes en ce qui concerne l'entreprise elle-même. (L'intégrité est discutée

en détail au fur et à mesure du déroulement du processus de conception.)

• Indépendance des données logiques et physiques par rapport aux

applications de base de données : ni les modifications apportées par un

utilisateur à la conception logique de la base de données ni les modifications

apportées par un fournisseur de logiciels de base de données à la mise en

œuvre physique de la base de données ne doivent nécessairement affecter

négativement les applications construites sur celle-ci.

• Cohérence et précision des données garanties : Les données sont

cohérentes et précises grâce aux différents niveaux d'intégrité que vous

pouvez imposer au sein de la base de données. (Cela deviendra très clair au

fur et à mesure que vous progresserez dans le processus de conception.)

• Récupération facile des données : un utilisateur peut récupérer des données

soit à partir d'une table particulière, soit à partir de n'importe quel nombre

de tables associées dans la base de données. Cela permet à l'utilisateur de

visualiser les informations d'un nombre presque illimité de façons.

Ces avantages, parmi d’autres, se sont révélés bénéfiques pour le monde des

affaires et pour tous ceux qui ont besoin de collecter et de gérer des

données. En effet, la base de données relationnelle reste la base de données

de choix dans de nombreuses circonstances.

L’un des inconvénients généralement perçus de la base de données

relationnelle était que les logiciels qui en découlent s’exécutent très

lentement. Ce n'était pas une faute du modèle relationnel lui-même, mais de la

technologie auxiliaire disponible au moment de l'introduction du modèle. La

vitesse de traitement, la mémoire et le stockage étaient tout simplement

insuffisants pour fournir aux fournisseurs de logiciels de bases de données une

plate-forme sur laquelle construire une implémentation complète de la base de

données relationnelle, de sorte que les logiciels de bases de données

relationnelles initiaux étaient loin d'atteindre leur plein potentiel. Les progrès

de la technologie matérielle et de l'ingénierie logicielle au cours des cinquante

dernières années ont fait des vitesses de traitement et de lecture/écriture un

problème insignifiant et ont permis aux fournisseurs de réaliser des gains

significatifs dans leurs efforts pour prendre en charge plus complètement le

modèle.
Vous en apprendrez davantage sur le modèle de base de données relationnelle

au fur et à mesure du processus de conception présenté dans ce livre. Certains

des sujets que vous rencontrerez incluent la création de tables, l'établissement

de l'intégrité des données, l'utilisation de relations et l'établissement de règles

métier.

Systèmes de gestion de bases de données relationnelles

Un système de gestion de base de données relationnelle (SGBDR) est un

programme d'application logiciel que vous utilisez pour créer, maintenir,

modifier et manipuler une base de données relationnelle. De nombreux

programmes SGBDR fournissent également les outils dont vous avez besoin

pour créer une grande variété d'applications utilisateur final qui interagissent

avec les données stockées dans la base de données. Bien entendu, la qualité

d'un SGBDR estune fonction directe de la mesure dans laquelle il prend en

charge le modèle de base de données relationnelle. Même parmi les « vrais »

SGBDR, la prise en charge de la base de données relationnelle varie selon les

fournisseurs, et il n'y a pas encore de mise en œuvre complète du potentiel du

modèle relationnel. Malgré cela, les programmes SGBDR continuent d’évoluer

et deviennent plus complets et plus puissants que jamais. Des exemples de

SGBDR incluent IBM DB2, IBM Informix, Microsoft Access, Microsoft SQL Server,

MySQL, Oracle RDBMS, PostgreSQL, SAP SQL Anywhere, SAP Sybase ASE et

SQLite.

Et après?

Et après? C'est une très bonne question. Je crois que la technologie, le génie

logiciel et l’industrie des bases de données dans son ensemble ont évolué plus

rapidement que quiconque aurait pu l’imaginer. Vous pourriez dire : « Mais

Mike, ça fait 50 ans ! » Et je dirais oui, mais quelle période de 50 ans cela a

été !
Quand j'étais un très jeune garçon, lisant des bandes dessinées de super-héros

et de science-fiction, les voitures, les gadgets, les espaces de vie et la

technologie en général semblaient appartenir à un avenir très lointain. Bien

sûr, je lisais des bandes dessinées de science-fiction qui racontaient des

histoires de personnes volant dans des voitures et utilisant de petits dispositifs

personnels anti-gravité, le tout se déroulant au milieu des années

1990 ! (J'attends toujours ma ceinture de vol personnelle, merci beaucoup !) Au

début de mon adolescence, j'ai regardé une fantastique émission futuriste

appelée « Star Trek » qui montrait des gens utilisant de petits appareils

portables et des badges comme moyens de communication ; ordinateurs

parlants; moniteurs à écran plat; réplicateurs d’aliments – la liste est longue. Je

me demandais : « Mon garçon, serai-je encore en vie pour voir et utiliser tous

ces trucs sympas ?

Avance rapide jusqu’à la fin des années 70, 80 et 90. Nous avons désormais

des ordinateurs qui s'adaptent aux ordinateurs de bureau, aux téléphones

mobiles, aux smartphones, aux écrans plats et aux écrans de télévision, et

c'est la naissance d'Internet. Les ordinateurs sont censés nous faciliter la vie,

nous permettre de faire les choses de manière plus efficace et efficiente et

éliminer pratiquement tous les types de formulaires et de rapports papier.

Passons maintenant aux années 2000. Nous avons d'énormes téléviseurs à

écran plat. Nos téléphones intelligents ont, pour beaucoup d’entre nous,

remplacé nos appareils photo et nos enregistreurs vidéo. La chose la plus

fantastique, à mon avis, est la quantité de puissance de calcul dont nous

disposons désormais littéralement au bout de nos doigts. Au début, les

mégaoctets étaient stockés dans des ordinateurs qui occupaient des pièces

entières climatisées, et les gigaoctets étaient une mesure d'espace de

stockage que nous pensions être dans des décennies. Désormais, les

consommateurs parlent de téraoctets sans hésiter ; vous pouvez acheter des

smartphones avec un téraoctet de capacité de stockage. Un téraoctet. Oui,

nous avons parcouru un long chemin. Incroyable.

Pourquoi est-ce que j’évoque les avancées technologiques ? Parce qu’ils ont eu

un impact sur les systèmes de gestion de bases de données relationnelles et

ont fourni une base pour le développement et l’utilisation de systèmes non

relationnels.
Autrefois, les éditeurs de logiciels de bases de données avaient du mal à

mettre en œuvre la base de données relationnelle en raison de certains aspects

du modèle. Par exemple, les requêtes multi-tables étaient initialement difficiles

à mettre en œuvre. La création et l'affichage d'une requête donnée pouvaient

prendre beaucoup de temps de traitement si elle extrayait des données à partir

d'un certain nombre de tables, en particulier si les tables contenaient un grand

nombre d'enregistrements. De plus, l'impression des rapports basés sur cette

requête prendrait du temps, pour les mêmes raisons. Mais les progrès

technologiques en matière de vitesse de traitement de la mémoire et de

lecture et d’écriture sur disque ont rendu ce problème bien moins

problématique. Ces progrès ont également permis aux systèmes de gestion de

bases de données relationnelles de devenir plus robustes et évolutifs et de

prendre en charge un niveau d'intégrité des données plus élevé que par le

passé.

Au cours des dernières années, il est devenu nécessaire de stocker des

données et des objets qui ne s'intègrent pas parfaitement dans la structure

table/champ/enregistrement du modèle de base de données relationnelle. Les

éléments tels que les photos, les données en lecture seule pour les applications

Web, les données graphiques, les données géospatiales et les données

analytiques sont des exemples de types de données qui ne correspondent pas

tout à fait à un modèle relationnel. Les progrès technologiques ont fourni aux

utilisateurs les outils de base qui leur permettent de créer de nouveaux types

de bases de données et de systèmes de gestion de bases de données capables

de gérer ces types de données, alors qu'avant c'était le cas.impossible de le

faire. Des exemples de ces systèmes de bases de données incluent MongoDB,

Couchbase, HBase, Cassandra et Redis.

Comme je l'ai mentionné plus tôt, le modèle de base de données relationnelle a

50 ans et je pense qu'il existera encore plusieurs années par la suite. Pourquoi

suis-je si optimiste ? Parce que les bases de données relationnelles sont

utilisées partout, elles font partie intégrante de nos vies. Ils pilotent tout, des

systèmes de petite entreprise aux systèmes collaboratifs départementaux en

passant par les systèmes d'entreprise à l'échelle de l'entreprise. Ils sont utilisés

sur les ordinateurs de bureau, les réseaux d’entreprise et même sur les

appareils personnels. Les bases de données relationnelles sont faciles à utiliser

et à entretenir, elles sont excellentes pour mettre en œuvre et faire respecter

l'intégrité des données, elles ont des structures solides (lorsqu'elles sont

correctement construites), elles sont évolutives et répondent au besoin d'une

base de données dans la majorité des cas. . (Mais sachez, d’un point de vue

pragmatique, que la base de données relationnelle n’est pas une construction «

universelle ».)

Je suis également optimiste en raison de cette citation d'un article daté du 14

août 2019, intitulé « Meilleure base de données relationnelle » du site Web

Database Trends and Applications . « Selon Craig S. Mullins, président et

consultant principal de Mullins Consulting, Inc, le relationnel continue de

dominer : IDC prévoit que les bases de données relationnelles représenteront

encore plus de 80 % du marché total des bases de données opérationnelles

jusqu'en 2022, et Gartner prévoit qu'à travers En 2020, la technologie

relationnelle continuera à être utilisée pour au moins 70 % des nouvelles

applications et projets. Même si ces projections restent relativement stables

pour les 10 prochaines années, les bases de données relationnelles

représentent toujours une part assez importante du marché des bases de

données.

Joyeux anniversaire, base de données relationnelle !

Résumé

Nous avons ouvert ce chapitre en définissant le terme base de données et en

décrivant les deux types de bases de données actuellement utilisées dans la

gestion de bases de données : opérationnelles et analytiques.

Ensuite, il y a eu une discussion détaillée du modèle de base de données

relationnelle, de son historique et de ses fonctionnalités. Vous avez appris qu’il

est basé sur des branches spécifiques des mathématiques et que ce

fondement mathématique est ce qui rend le modèle si structurellement

solide. Nous avons ensuite exploré les structures et les relations des données

du modèle ainsi que le rôle que joue SQL dans l'accès aux données au sein du

modèle. Ici, vous avez appris que SQL est le langage standard utilisé pour

travailler avec des bases de données relationnelles. Nous avons conclu cette

section en passant en revue les avantages du modèle de base de données

relationnelle et en définissant ce qu'est un système de gestion de base de

données relationnelle. Vous avez appris comment les progrès technologiques

ont eu un impact sur notre vie quotidienne et à quel point cet impact est

omniprésent. Vous avez également appris ce qui a permis à la base de données

relationnelle d'exister depuis 50 ans et l'impact du SGBDR dans tous les types

de scénarios commerciaux.

Le chapitre suivant explique pourquoi vous devriez vous préoccuper de la

conception de bases de données et pourquoi la théorie est importante. Nous

aborderons également les objectifs et les avantages d’une bonne conception.

Questions de révision

1. Nommez les deux principaux types de bases de données utilisées

aujourd’hui.
2. Quel type de données une base de données analytique stocke-t-elle ?

3. Vrai ou faux : une base de données opérationnelle est principalement

utilisée dans les scénarios de traitement des transactions en ligne (OLTP).

4. Nommez une des branches des mathématiques sur laquelle est basé le

modèle relationnel.

5. Comment une base de données relationnelle stocke-t-elle les données ?

6. Nommez les trois types de relations dans une base de données relationnelle.

7. Comment récupérer des données dans une base de données relationnelle ?

8. Énoncez deux avantages d’une base de données relationnelle.

9. Qu'est-ce qu'un système de gestion de base de données relationnelle ?

10. Vrai ou faux : les appareils mobiles sont limités à des gigaoctets de

stockage.

11. Expliquez pourquoi les éditeurs de logiciels de bases de données ont eu du

mal à mettre en œuvre la base de données relationnelle.

t
adqP
r
bouae
lserc
euah
e
m
dèr
etc
srh
e
m
s
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
1. La base de données relationnelle
2. Objectifs de conception
3. Terminologie
8h 33min restantes

Objectifs de conception

Tout ce qui est factuel est, en un sens, théorie. Le bleu du ciel présente les lois
fondamentales de la chromatique. Cela n’a aucun sens de chercher quelque
chose derrière les phénomènes ; ce sont de la théorie.

—G OETHE

Sujets abordés dans ce chapitre

Pourquoi devriez-vous vous préoccuper de la conception de bases de données ?

L'importance de la théorie

L'avantage d'apprendre une bonne méthodologie de conception

Objectifs d'une bonne conception

Avantages d’une bonne conception

Méthodes de conception de bases de données

Normalisation

Résumé

Questions de révision

Pourquoi devriez-vous vous préoccuper de la conception de

bases de données ?

Certains d'entre vous qui travaillent avec des programmes d'application de

systèmes de gestion de bases de données relationnelles (SGBDR) se

demandent peut-être pourquoi vous devriez vous préoccuper de la conception

de bases de données. Après tout, la plupart des programmes sont livrés avec

des exemples de bases de données que vous pouvez copier et modifier selon

vos propres besoins, et vous pouvez même emprunter des tables à partir des

exemples de bases de données etutilisez-les dans d'autres bases de données

que vous avez créées. Certains programmes fournissent également des outils

qui vous guideront tout au long du processus de définition et de création de

tableaux. Cependant, ces outils ne vous aident pas réellement à concevoir une

base de données : ils vous aident simplement à créer les tables physiques que

vous inclurez dans la base de données.

Ce que vous devez comprendre, c'est qu'il est préférable d'utiliser ces

outils après avoir créé la structure logique de la base de données . Les

programmes SGBDR fournissent les outils de conception et les exemples de

bases de données pour vous aider à minimiser le temps nécessaire à la mise

en œuvre physique de la structure de la base de données. Théoriquement, la

réduction du temps de mise en œuvre vous donne plus de temps pour vous

concentrer sur la création et la création d'applications pour les utilisateurs

finaux.

Pourtant, la principale raison pour laquelle vous devriez vous préoccuper de la

conception d’une base de données est qu’elle est cruciale pour la cohérence,

l’intégrité et l’exactitude des données contenues dans une base de données. Si

vous concevez mal une base de données, il vous sera difficile de récupérer

certains types d'informations et vous courrez le risque que vos recherches

produisent des informations inexactes. Des informations inexactes sont

probablement le résultat le plus préjudiciable d'une mauvaise conception de

base de données : elles peuvent nuire aux résultats de votre organisation. En
fait, si votre base de données affecte la manière dont votre entreprise effectue

ses opérations quotidiennes, ou si elle va influencer l'orientation future de

votre entreprise, vous devez vous préoccuper de la conception de la base de

données.
Examinons cela sous un angle différent pendant un moment : réfléchissez à la

façon dont vous procéderiez pour faire construire une maison sur

mesure. Quelle est la première chose que vous allez faire ? Vous n’allez

certainement pas embaucher un entrepreneur immédiatement et le laisser

construire votre maison comme il le souhaite. Vous engagerez sûrement

d’abord un architecte pour concevoir votre nouvelle maison ,

puis embaucherez un entrepreneur pour la construire. L'architecte explorera
vos besoins et les exprimera sous la forme d'un ensemble de plans,

enregistrant les décisions concernant la taille, la forme et les exigences des

divers systèmes (structurels, mécaniques, électriques). Ensuite, l'entrepreneur

se procurera la main-d'œuvre et les matériaux, y compris les systèmes

répertoriés, puis les assemblera selon les dessins et les spécifications.

Revenons maintenant à notre perspective de base de données et considérons

la conception logique de la base de données comme les plans architecturaux et

la mise en œuvre physique de la base de données comme la maison

achevée. La conception logique de la base de données décrit la taille, la forme

et les systèmes nécessaires à votre base de données, et répond aux besoins

informationnels et opérationnels de votre entreprise. Vous construisez ensuite

l'implémentation physique de la conception logique de la base de données à

l'aide de votre programme SGBDR. Après avoir créé vos tables, configuré les

relations entre les tables et établi les niveaux appropriés d'intégrité des

données, votre base de données est terminée. Vous êtes désormais prêt à

concevoir et à créer des applications qui vous permettent, à vous et à vos

utilisateurs, d'interagir facilement avec les données stockées dans la base de

données, et vous pouvez être sûr que ces applications vous fourniront des

informations opportunes et, surtout, précises sur lesquelles vous pourrez vous

baser. peut prendre des décisions commerciales judicieuses.

Bien que vous puissiez implémenter une mauvaise conception dans un SGBDR,

la mise en œuvre d'une bonne conception est bien plus à votre avantage car

elle produira des informations précises, stockera les données de manière plus

efficace et efficiente et sera plus facile à gérer et à maintenir.

L'importance de la théorie

Note

Dans ce chapitre, j'utilise le terme théorie pour représenter des « propositions

générales utilisées comme principes » et non des « conjectures ou propositions

».

Un certain nombre de disciplines majeures (et leurs méthodologies de

conception associées) ont une certaine forme de base théorique. Les

ingénieurs en structures conçoivent une variété illimitée de structures en

utilisant les théories de la physique. Les compositeurs créent de belles

symphonies et des pièces orchestrales en utilisant les concepts trouvés dans la

théorie musicale. L'industrie automobile utilise des théories aérodynamiques

pour concevoir des véhicules plus économes en carburant. L’industrie

aérospatiale utilise les mêmes théories pour concevoir des avions et des engins

spatiaux.
Ces exemples démontrent que la théorie est pertinente et très importante. Le

principal avantage de la théorie est qu’elle vous aide à prédire les

résultats ; cela vous permet de prédire ce qui se passera probablement si vous

effectuez une certaine action ou série d'actions. Vous savez, si vous laissez

tomber une pierre, elle tombera au sol. Sir Isaac Newton a formulé une théorie

de la gravité à la fin du XVIIe siècle , que nous considérons aujourd'hui comme

une loi. Si vous êtes agile, vous pouvez écarter vos orteils de la loi de la gravité

de Newton avant qu'ils ne soient écrasés par la chute de pierre. Le fait est

qu’une fois que la théorie devient loi, elle fonctionne à chaque fois . Si vous

ciselez une pierre à plat et la placez sur une autre pierre plate, vous pouvez

prédire qu'elle restera là où vous l'avez posée. Cette théorie permet de

concevoir des pyramides, des cathédrales et des bâtiments résidentiels

stylisés. Considérons maintenant un exemple de base de données. Supposons

que vous disposiez de deux tables liées les unes aux autres. Vous savez que

vous pouvez extraire des données des deux tables simultanément simplement

en raison du fonctionnement de la théorie des bases de données

relationnelles. Les données que vous extrayez des deux tables sont basées sur

les valeurs correspondantes d'un champ partagé entre les tables elles-

mêmes. Encore une fois, vos actions ont un résultat prévisible.

La base de données relationnelle est basée sur deux branches des

mathématiques connues sous le nom de théorie des ensembles et de logique

des prédicats du premier ordre . C’est précisément ce qui permet à la base de

données relationnelle de garantir des informations précises. Ces branches des

mathématiques fournissent également la base pour formuler de bonnes

méthodologies de conception et les éléments de base nécessaires pour créer

de bonnes structures de bases de données relationnelles.

Vous pourriez éprouver une réticence compréhensible à étudier des concepts

mathématiques compliqués simplement pour accomplir ce qui semble être une

tâche plutôt limitée. À ce jour, vous êtes toujours sûr d'entendre des

affirmations selon lesquelles les théories mathématiques sur lesquelles sont

basées la base de données relationnelle et ses méthodologies de conception

associées n'ont aucune pertinence avec le monde réel, ou sont d'une manière

ou d'une autre peu pratiques. Ce n'est pas vrai : les mathématiques sont au

cœur du modèle relationnel et c'est ce qui garantit la viabilité du modèle. Mais

rassurez-vous, vous n'avez pas vraiment besoin de savoir quoi que ce soit

surthéorie des ensembles ou logique des prédicats du premier ordre pour

utiliser une base de données relationnelle ! Vous n’avez certainement pas

besoin de connaître tous les détails de l’aérodynamique simplement pour

conduire une automobile ou piloter un avion. Les théories aérodynamiques

peuvent vous aider à comprendre et à apprécier comment une automobile peut

obtenir une meilleure consommation d'essence, mais elles ne vous aideront

pas à apprendre à vous garer en parallèle.

La théorie mathématique constitue la base du modèle de base de données

relationnelle et rend ainsi le modèle prévisible, fiable et solide. La théorie décrit

les éléments de base utilisés pour créer une base de données relationnelle et

fournit des lignes directrices sur la manière dont elle doit être

organisée. Disposer les éléments de base pour obtenir un résultat souhaité est

défini comme la conception .

L'avantage d'apprendre une bonne méthodologie de
conception

Vous pourriez apprendre à concevoir correctement une base de données par

essais et erreurs, mais cela vous prendrait très longtemps et vous devrez

probablement réparer de nombreuses erreurs en cours de route. La meilleure

approche consiste à apprendre une bonne méthodologie de conception de base

de données, comme celle présentée dans ce livre, puis à se lancer dans la

conception de votre base de données.

Vous bénéficierez de plusieurs avantages en apprenant et en utilisant une

bonne méthodologie de conception :

• Il vous donne les compétences dont vous avez besoin pour concevoir une

structure de base de données solide. Un grand nombre de problèmes de

traitement des données peuvent être attribués à la présence de données

redondantes, de données en double et de données invalides, ou à l'absence

de données requises. Tous ces problèmes produisent des informations

erronées et rendent certaines requêtes et rapports difficiles à comprendre

ou les rendent relativement dénués de sens. Vous pouvez éviter presque

tous ces problèmes en employant une bonne méthodologie de conception.

• Il vous fournit un ensemble organisé de techniques qui vous guideront étape

par étape tout au long du processus de conception . L'organisation des

techniques vous permet de prendre des décisions éclairées sur chaque

aspect de votre conception.

• Cela vous aide à minimiser vos faux pas et vos réitérations de

conception . Bien sûr, vous ferez naturellement des erreurs lorsque vous
concevrez une base de données, mais une bonne méthodologie vous aide à

reconnaître les erreurs dans votre conception et vous donne les outils pour

les corriger. De plus, l’organisation des techniques au sein de la

méthodologie vous évite de répéter inutilement une étape de conception

donnée.

• Cela facilite le processus de conception et réduit le temps que vous

consacrez à la conception de la base de données. Vous perdrez

inévitablement un temps précieux à adopter une approche arbitraire de

conception par essais et erreurs, car elle manque de la logique et de

l’organisation qu’offre une bonne méthodologie.

• Il vous aidera à comprendre et à utiliser votre programme d'application

SGBDR de manière plus complète et plus efficace. Au fur et à mesure que

vos connaissances en matière de conception appropriée s'étendent et se

développent, vous commencerez réellement à comprendre pourquoi un

SGBDR donné fournit certains outils et comment vous pouvez les utiliser

pour implémenter la structure au sein du programme SGBDR.

Que vous utilisiez la méthodologie de conception présentée dans ce livre ou

une autre méthodologie établie, vous devez choisir une méthodologie de

conception, l'apprendre du mieux que vous pouvez et l'utiliser fidèlement pour

concevoir vos bases de données.

Objectifs d'une bonne conception

Vous devez atteindre des objectifs distincts pour concevoir une structure de

base de données bonne et solide. Vous pouvez éviter bon nombre des

problèmes mentionnés dans lesection précédente si vous gardez ces objectifs à

l'esprit et si vous vous concentrez constamment sur eux pendant que vous

concevez votre base de données.

• La base de données prend en charge la récupération d'informations requises

et ad hoc. La base de données doit stocker les données nécessaires pour

prendre en charge les exigences d'information définies lors du processus de

conception et toutes les éventuelles requêtes ad hoc pouvant être posées

par un utilisateur.

• Les tables sont construites correctement et efficacement. Chaque table de

la base de données représente un sujet unique, est composée de champs

relativement distincts, limite les données redondantes au minimum absolu

et est identifiée dans toute la base de données par un champ avec des

valeurs uniques.

• L'intégrité des données est imposée au niveau du champ, de la table et des

relations. Ces niveaux d'intégrité permettent de garantir que les structures

de données et leurs valeurs seront valides et exactes à tout moment.

• La base de données prend en charge les règles métier pertinentes pour

l'organisation. Les données doivent fournir des informations valides et

précises qui sont toujours significatives pour l'entreprise.

• La base de données se prête à une croissance future . La structure de la

base de données doit être facile à modifier ou à étendre à mesure que les

besoins d'information de l'entreprise évoluent et augmentent.

Il vous sera peut-être parfois difficile d'atteindre ces objectifs, mais vous serez

certainement satisfait de la structure finale de votre base de données une fois

que vous les aurez atteints.

Avantages d’une bonne conception

Le temps que vous investissez dans la conception d’une structure de base de

données solide est du temps bien dépensé. Une bonne conception vous fait

gagner du temps à long terme car vous n'avez pas constamment à réorganiser
un système rapidement et mal conçu.structure. Vous bénéficiez des avantages

suivants lorsque vous appliquez de bonnes techniques de conception :

• La structure de la base de données est facile à modifier et à maintenir. Les

modifications que vous apportez à un champ, une table ou une relation ne

doivent pas nécessairement affecter négativement les autres champs,

tables ou relations de la base de données.

• Les données sont faciles à modifier. Les modifications que vous apportez à

la valeur d’un champ donné dans une table n’affecteront pas les valeurs des

autres champs de la table. De plus, une base de données bien conçue réduit

les champs en double au minimum absolu, de sorte que vous modifiez

généralement une valeur de données particulière dans un seul champ.

• Les informations sont faciles à récupérer. Vous pourrez créer des requêtes

facilement car les tables sont bien construites et les relations entre elles

sont correctement établies. Les relations entre tables sont assez évidentes

dans une base de données bien conçue, même lorsqu'elles ne sont pas

appliquées.

• Les applications des utilisateurs finaux sont faciles à développer et à

créer. Vous pouvez consacrer plus de temps à la programmation et à la

manipulation des données au lieu de contourner les inévitables problèmes

qui surviennent lorsque vous travaillez avec une base de données mal

conçue.

Méthodes de conception de bases de données

Méthodes de conception traditionnelles

En général, les méthodes traditionnelles de conception de bases de données

intègrent trois phases : l'analyse des exigences, la modélisation des données et

la normalisation.
La phase d'analyse des besoins implique un examen de l'entreprise modélisée,

des entretiens avec les utilisateurs et la direction pour évaluer le système

actuel et analyser les besoins futurs, ainsi qu'une évaluation des besoins en

informations pour l'entreprise dans son ensemble. Ce processus

estrelativement simple et, en effet, le processus de conception présenté dans

ce livre suit la même ligne de pensée.

La phase de modélisation des données implique la modélisation de la structure

de la base de données à l'aide d'une méthode de modélisation des données,

telle que la création de diagrammes entité-relation (ER), la modélisation objet

sémantique, la modélisation objet-rôle ou la modélisation UML. Chacune de ces

méthodes de modélisation fournit un moyen de représenter visuellement divers

aspects de la structure de la base de données, tels que les tables, les relations

entre les tables et les caractéristiques des relations. En fait, la méthode de

modélisation utilisée dans ce livre est une version de base des diagrammes

ER. La figure 2.1 montre un exemple de diagramme ER de base.

Figure 2.1 Un exemple de diagramme ER de base.

Note

J'ai incorporé la méthode de modélisation des données que j'utilise dans ce

livre dans le processus de conception lui-même plutôt que de la traiter

séparément. Je vais présenter et expliquer chaque technique de modélisation,

le cas échéant tout au long du processus.

Chaque méthode de modélisation de données intègre un ensemble de

symboles de diagramme utilisés pour représenter la structure et les

caractéristiques d'une base de données. Par exemple, le diagramme de la

figure 2.1 fournit des informations sur plusieurs aspects de la base de données.

• Les rectangles représentent deux tableaux appelés AGENTS et CLIENTS.

• Le losange représente une relation entre ces deux tables, et le « 1 : N » à

l'intérieur du losange indique qu'il s'agit d'une relation un-à-plusieurs.

• La ligne verticale à côté du tableau AGENTS indique qu'un client doit être

associé à un seul agent, et le cercle etLa « patte d'oie » à côté de la table

CLIENTS indique qu'un agent ne doit pas nécessairement être associé à un

client, mais peut être associé à un ou plusieurs.

Les champs sont également définis et associés aux tables appropriées lors de

la phase de modélisation des données. Chaque table se voit attribuer une clé

primaire , différents niveaux d'intégrité des données sont identifiés et mis en

œuvre, et les relations sont établies via des clés étrangères . Une fois les

structures de tables initiales terminées et les relations établies selon le modèle

de données, la base de données est prête à passer par la phase de

normalisation.
La normalisation est le processus de décomposition de grandes tables en

tables plus petites afin d'éliminer les données redondantes et les données en

double et d'éviter les problèmes d'insertion, de mise à jour ou de suppression

de données. Au cours du processus de normalisation, les structures des tables

sont testées par rapport aux formes normales , puis modifiées si l'un des

problèmes mentionnés ci-dessus est détecté. Un formulaire normal est un

ensemble spécifique de règles qui peuvent être utilisées pour tester une

structure de table afin de garantir qu'elle est solide et exempte de

problèmes. Il existe un certain nombre de formes normales, et chacune est

utilisée pour tester un ensemble particulier de problèmes. Les formes normales

actuellement utilisées sont la première forme normale, la deuxième forme

normale, la troisième forme normale, la quatrième forme normale, la cinquième

forme normale, la sixième forme normale, la forme normale de Boyce-Codd et

la forme normale de domaine/clé.

La méthode de conception présentée dans ce livre

La méthode de conception que j'utilise dans ce livre est celle que j'ai

développée au fil des années. Il intègre une analyse des besoins et une

méthode simple de création de diagrammes ER pour schématiser la structure

de la base de données. Cependant, il n’intègre pas le processus de

normalisation traditionnel et n’implique pas l’utilisation de formes normales. La

raison est simple : les formes normales peuvent être déroutantes pour

quiconque n'a pas pris le temps d'étudier les formes formelles.théorie des

bases de données relationnelles. Par exemple, examinez la définition suivante

de la troisième forme normale :

Une relation est en 3NF si et seulement si elle est en 2NF et que chaque

attribut non-clé dépend de manière non transitive de la clé primaire. 1

1. CJ Date, Une introduction aux systèmes de bases de données , 7e

éd. (Boston, MA : Addison-Wesley, (2000), 362.

Cette description n'a relativement aucun sens pour un lecteur qui n'est pas

familier avec les termes relation, 3NF, 2NF, attribut non clé, dépendance non

transitive et clé primaire.

Le processus de conception d’une base de données n’est pas et ne devrait pas

être difficile à comprendre. Tant que le processus est présenté de manière

simple et que chaque concept ou technique est clairement expliqué, n'importe

qui devrait être capable de concevoir correctement une base de données. Par

exemple, la définition suivante est dérivée des résultats de l’utilisation de la

troisième forme normale sur une structure de table, et je pense que la plupart

des gens la trouveront claire et facile à comprendre :

Une table doit avoir un champ qui identifie de manière unique chacun de ses

enregistrements, et chaque champ de la table doit décrire le sujet représenté

par la table.

Le processus que j'ai utilisé pour formuler cette définition est le même que

celui que j'ai utilisé pour développer l'ensemble de ma méthodologie de

conception.
Normalisation

À la fin des années 1980, je me suis rendu compte que le modèle relationnel

existait depuis près de 20 ans et que les gens concevaient des bases de

données en utilisant la même méthodologie de base depuis environ 12 ans. (Et

je suis toujours surpris que nous l'utilisions plus de 20 ans plus tard.) J'utilisais

la méthodologie de conception traditionnelle à cette époque, mais jeil leur était

parfois difficile de trouver un emploi. Les deux choses qui m'ont le plus

dérangé étaient le processus de normalisation (dans son ensemble) et les

itérations apparemment interminables qu'il a fallu pour arriver à une

conception appropriée. Bien sûr, cela semblait être un point sensible chez la

plupart des autres développeurs de bases de données que je connaissais, donc

je n'étais certainement pas seul dans mes frustrations. J'ai réfléchi à ces

problèmes pendant un certain temps, puis j'ai trouvé une solution.

Je savais déjà que le but de la normalisation est de prendre une table mal ou

mal conçue et de la transformer en une table avec une structure solide. J'ai

également compris le processus : prenez un tableau donné et testez-le par

rapport aux formulaires normaux pour déterminer s'il est correctement

conçu. S'il n'est pas conçu correctement, apportez les modifications

appropriées, testez-le à nouveau et répétez l'ensemble du processus jusqu'à ce

que la structure du tableau soit saine. La figure 2.2 montre comment j'ai

visualisé le processus à ce stade.

Figure 2.2 Comment j'ai perçu le processus général de normalisation.

J'ai gardé ces faits à l'esprit et j'ai ensuite posé les questions suivantes :

1. Si nous supposons qu'une table entièrement normalisée est conçue

correctement et efficacement, ne pourrions-nous pas identifier les

caractéristiques spécifiques d'une telle table et les considérer comme les

attributs d'une structure de table idéale ?

2. Ne pourrions-nous pas alors utiliser cette table idéale comme modèle pour

toutes les tables que nous créons pour la base de données tout au long du

processus de conception ?
La réponse à ces deux questions est bien sûr oui, c’est pourquoi j’ai commencé

sérieusement à développer les bases de ma « nouvelle » méthodologie de

conception. J'ai d'abord compilé des ensembles distincts de lignes directrices

pour créer des structures sonores en identifiant les caractéristiques finales

d'une base de données bien définie qui a réussi les tests de chaque forme

normale. J'ai ensuite effectué quelques tests, en utilisant les nouvelles

directives, pour créer des structures de tables pour une nouvelle base de

données et pour corriger des défauts dans les structures de tables d'une base

de données existante. Ces tests se sont très bien déroulés, j'ai donc décidé

d'appliquer cette technique à l'ensemble de la méthodologie de conception

traditionnelle. J'ai formulé des lignes directrices pour résoudre d'autres

problèmes associés à la méthode de conception traditionnelle, tels que les

domaines, les sous-types, les relations, l'intégrité des données et l'intégrité

référentielle. Après avoir suivi les nouvelles directives, j'ai effectué davantage

de tests et j'ai constaté que ma méthodologie fonctionnait plutôt bien.

Le principal avantage de ma méthodologie de conception est qu’elle supprime

de nombreux aspects de la méthodologie de conception traditionnelle que les

nouveaux développeurs de bases de données trouvent intimidants. Par

exemple, la normalisation, au sens traditionnel, est désormais transparente

pour le concepteur car elle est intégrée (via les nouvelles lignes directrices)

tout au long du processus de conception. Un autre avantage majeur est que la

méthodologie est claire et facile à mettre en œuvre. Je pense que cela est dû

en grande partie au fait que j'ai rédigé toutes les directives dans un anglais

simple, ce qui les rend faciles à comprendre pour la plupart des gens.
Il est important que vous compreniez que cette méthodologie de conception

produira une structure de base de données entièrement

normalisée uniquement si vous la suivez aussi fidèlement que n'importe quelle

autre méthodologie de conception . Vous ne pouvez pas raccourcir, contourner,

minimiser ou omettre une quelconque partie de cette méthodologie (ou toute

méthodologie de conception, d'ailleurs) et espérer développer une structure

solide. Vous devez suivre le processus avec diligence, méthodique et

complètement afin de récolter les fruits attendus.

Note

J'ai fourni une explication plus détaillée de la façon dont j'ai intégré la

normalisation dans ma méthodologie de conception dans l'annexe G , « Sur la

normalisation ».

Vous devrez apprendre quelques termes de base avant de vous lancer dans le

processus de conception, et nous les aborderons dans le chapitre suivant.

Résumé

Au début de ce chapitre, nous avons examiné l'importance de se préoccuper de

la conception des bases de données. Vous comprenez maintenant que la

conception d’une base de données est cruciale pour l’intégrité et la cohérence

des données contenues dans une base de données. Nous avons vu que le

principal problème résultant d'une conception inappropriée ou médiocre

est l'information inexacte . Une bonne conception est d’une importance

primordiale, car une mauvaise conception peut nuire aux informations utilisées

par une organisation.

Ensuite, nous avons entamé une discussion sur l’importance de la théorie, ainsi

que sur sa pertinence pour le modèle de base de données relationnelle. Vous

avez appris que le fondement du modèle en théorie mathématique en fait une

structure très solide et fiable.

Suite à cette discussion, nous avons examiné les avantages tirés de

l’apprentissage d’une méthodologie de conception. Entre autres choses,

l’utilisation d’une bonne méthodologie permet d’obtenir une structure de base

de données efficace et fiable, de réduire le temps nécessaire à la conception

d’une base de données et d’éviter les problèmes typiques causés par une

mauvaise conception.

Ensuite, nous avons énuméré les objectifs d’une bonne conception. Atteindre

ces objectifs est crucial pour le succès du processus de conception de base de

données, car ils vous aident à garantir que la structure de la base de données

est solide. Nous avons ensuite énuméré les avantages d’une bonne conception,

et vous avez appris que le temps que vous investissez dans la conception

d’une structure de base de données solide est du temps bien dépensé.

Nous avons clôturé ce chapitre par une brève discussion des méthodes

traditionnelles de conception de bases de données, une explication du principe

derrière la méthode de conception présentée dans ce livre et la

normalisation. Vous comprenez désormais que les méthodes de conception

traditionnelles sont complexes et peuvent prendre un certain temps.le temps

d'apprendre et de comprendre. D'un autre côté, la méthode de conception

utilisée dans ce livre est présentée de manière claire et directe, est facile à

mettre en œuvre et donnera les mêmes résultats que la méthodologie de

conception traditionnelle.
Questions de révision

1. Quel est le meilleur moment pour utiliser les outils de conception d'un

programme SGBDR ?

2. Vrai ou faux : la conception est cruciale pour la cohérence, l'intégrité et

l'exactitude des données.

3. Quel est le résultat le plus préjudiciable d’une mauvaise conception de base

de données ?

4. Qu'est-ce qui rend la base de données relationnelle structurellement solide

et capable de garantir des informations exactes ?

5. Énoncez deux avantages de l’apprentissage d’une méthodologie de

conception.

6. Vrai ou faux : vous utiliserez votre programme SGBDR plus efficacement si

vous comprenez la conception de bases de données.

7. Énoncez deux objectifs d’une bonne conception.

8. Qu'est-ce qui permet de garantir que les structures de données et leurs

t
valeurs sont valides et exactes à tout moment ?
a
b
l9. Énoncez deux avantages de l’application de bonnes techniques de
e
conception.
d
e
10. Vrai ou faux : vous pouvez prendre des raccourcis dans certains processus
s
P
arde conception tout en parvenant à une bonne conception solide.
rem
ac
dqm
ht
ouèei
setrè
urc
eeh
se
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
2. Objectifs de conception
3. Terminologie
Partie II : Le processus de conception
8h 33min restantes

Terminologie

"Quand j'utilise un mot", a déclaré Humpty Dumpty sur un ton plutôt

méprisant, "il signifie exactement ce que je choisis de lui signifier, ni plus ni
moins."

—L EWIS C ARROLL

À TRAVERS LE LOOKING G LASS

Sujets abordés dans ce chapitre

Pourquoi cette terminologie est importante

Termes liés à la valeur

Termes liés à la structure

Conditions liées aux relations

Termes liés à l'intégrité

Résumé

Questions de révision

Il est important que vous compreniez les termes de ce chapitre avant de vous

lancer dans l'apprentissage du processus de conception. En effet, vous devrez

apprendre d’autres termes, et je les aborderai au fur et à mesure du

processus. Il y a également un glossaire à la fin du livre que vous pouvez

utiliser pour vous rafraîchir la mémoire sur n'importe quel terme que vous

apprenez ici ou dans les chapitres suivants.

Pourquoi cette terminologie est importante

La conception de bases de données relationnelles possède son propre

ensemble de termes, tout comme toute autre profession, métier ou

discipline. Voici trois bonnes raisons pour lesquelles il est important que vous

appreniez ces termes.

1. Ils sont utilisés pour exprimer et définir les idées et concepts particuliers

du modèle de base de données relationnelle. Une grande partie de la

terminologie est dérivée des branches mathématiques de la théorie des

ensembles et de la logique des prédicats du premier ordre, qui constituent

la base du modèle de base de données relationnelle.

2. Ils sont utilisés pour exprimer et définir le processus de conception de base

de données lui-même. Le processus de conception devient plus clair et

beaucoup plus facile à comprendre une fois que vous connaissez ces

termes.
3. Ils sont utilisés partout où une base de données relationnelle ou un SGBDR

est abordé. Vous verrez ces termes dans des documents tels que des
manuels de logiciels en ligne, des supports de cours éducatifs, des livres sur

des logiciels de bases de données commerciales et des sites Web liés aux

bases de données.

Ce chapitre couvre la majorité des termes qui définissent les idées et les

concepts du processus de conception, y compris des définitions et des

discussions quelque peu détaillées pour chaque terme. (Je fournis des détails

pertinents ou une discussion plus approfondie nécessaire pour un terme donné

au moment où le terme est expressément utilisé dans une technique spécifique

du processus de conception.) Il y a plusieurs autres termes que j'introduis et

discute plus loin dans le livre parce que je pense que vous Je les comprendrai

plus facilement dans le contexte de l’idée ou du concept spécifique auquel ils

se rapportent.

Note

Le glossaire contient des définitions concises de tous les termes de ce chapitre

et de tout le livre.

Quatre catégories de termes sont définies dans ce chapitre : liés aux

valeurs, liés à la structure, liés aux relations et liés à l'intégrité .

Termes liés à la valeur

Données

Les valeurs que vous stockez dans la base de données sont des données . Les

données sont statiques dans le sens où elles restent dans le même état jusqu'à

ce que vous les modifiiez par un processus manuel ou automatisé. La figure

3.1 montre quelques exemples de données.

Figure 3.1 Un exemple de données de base.

Ces données n’ont aucun sens à ce stade. Par exemple, il n’existe pas de

moyen simple pour déterminer ce que « 92883 » représente. Est-ce un code

postal ? Est-ce un numéro de pièce ? Même si vous savez qu'il s'agit d'un

numéro d'identification de client, s'agit-il d'un numéro associé à George

Edleman ? Il n'y a tout simplement aucun moyen de le savoir tant que vous

n'avez pas traité les données.

Information

Les informations sont des données que vous traitez de manière à les rendre
significatives et utiles lorsque vous les utilisez ou les consultez. Il est

dynamique dans le sens où il change constamment par rapport aux données

stockées dans la base de données, et aussi dans le sens où vous pouvez les

traiter et les présenter d'un nombre illimité de façons. Vous pouvez afficher des

informations résultant d'une instruction SQL SELECT, les afficher sous un

formulaire sur l'écran de votre ordinateur ou les imprimer sous forme de

rapport. Le point à retenir est que vous devez traiter vos données d'une

manière ou d'une autre afin de pouvoir les transformer en informations

significatives .

La figure 3.2 montre comment vous pouvez traiter et transformer les données

de l'exemple précédent en informations significatives. Il a été manipulé de telle

manière – dans ce cas-ci, dans le cadre d’un rapport de facture d’un patient –

qu’il est désormais significatif pour quiconque le consulte.

Figure 3.2 Un exemple de données transformées en informations.

Il est très important que vous compreniez la différence entre les données et les

informations . Vous concevez une base de données pour fournir des

informations significatives à une personne au sein d'une entreprise ou d'une

organisation. Ces informations ne sont disponibles que si

les données appropriées existent dans la base de données et si la base de

données est structurée de manière à prendre en charge ces informations . Si

jamais vous oubliez la différence entre données et informations, rappelez-vous

simplement ce petit axiome :

Les données sont ce que vous stockez ; l'information est ce que

vous récupérez .
Lorsque vous comprendrez parfaitement ce concept simple et unique, la

logique derrière le processus de conception de base de données deviendra

limpide.

Note

Malheureusement, données et informations sont deux

termes encore fréquemment utilisés de manière interchangeable (et donc à

tort) dans l’industrie des bases de données. Vous rencontrerez cette erreur

dans de nombreux magazines spécialisés, livres de bases de données

commerciales et sites Web, et vous verrez même des termes utilisés à mauvais

escient par des auteurs qui devraient en savoir plus.

Nul

Null est une condition qui représente une valeur manquante ou inconnue. Vous
devez comprendre dès le départ qu'un Null ne représente pas un zéro ou une

chaîne de texte composée d'un ou plusieurs espaces vides. Les raisons sont

assez simples.

• Un zéro peut avoir des significations très diverses. Il peut représenter l'état

du solde d'un compte, le nombre actuel de surclassements de billets en

première classe disponibles ou le niveau de stock actuel d'un produit

particulier.
• Bien qu’une chaîne de texte contenant un ou plusieurs espaces vides soit

sans aucun doute dénuée de sens pour la plupart d’entre nous, elle est tout

à fait significative pour un langage de requête tel que SQL. Un espace est un

caractère valide en ce qui concerne SQL, et une chaîne de caractères

composée de trois espaces (' ') est tout aussi légitime qu'une chaîne de

caractères composée de trois lettres (' abc '). Dans la figure 3.3 , un blanc

représente le fait que Washington, DC, n'est situé dans aucun comté.

• Une chaîne de longueur nulle (deux guillemets simples consécutifs sans

espace entre eux ('')) est également une valeur acceptable pour des

langages tels que SQL et peut être significative dans certaines

circonstances. Dans une table EMPLOYEES, par exemple, une valeur de

chaîne de longueur nulle dans un champ appelé MIDDLEINITIAL peut

représenter le fait qu'un employé particulier n'a pas d'initiale dans son nom.

Note

En raison de restrictions d'espace, je ne peux pas toujours afficher tous les

champs d'un exemple de table donné. Je vais cependant montrer les champs

les plus pertinents pour la discussion en cours et utiliser « autres champs

» pour représenter les champs qui ne sont pas essentiels à l'exemple. Vous

verrez cette convention dans de nombreux exemples tout au long du reste du

livre.

La valeur de null

Null est très utile lorsque vous l'utilisez aux fins indiquées, et le tableau

CLIENTS de la figure 3.3 l'illustre clairement. Chaque valeur Null dans le champ

COMTÉ CLIENT représente un nom de comté manquant ou inconnu pour

l'enregistrement dans lequel il apparaît. Pour utiliser correctement les valeurs

Null, vous devez d’abord comprendre pourquoi elles se produisent.

Figure 3.3 Un exemple de table contenant des instances de Nulls.

Les valeurs manquantes sont généralement le résultat d’une erreur

humaine. Par exemple, considérons le record de Susan Black. Si vous saisissez

les données de Mme Black et que vous ne lui demandez pas le nom du comté

dans lequel elle vit, ces données sont considérées comme manquantes et sont

représentées dans l'enregistrement comme étant nulles. Cependant, après

avoir reconnu l'erreur, vous pouvez la corriger en appelant Mme Black et en lui

demandant le nom du comté.

Des valeurs inconnues apparaissent dans un tableau pour diverses raisons. Une
des raisons peut être qu'une valeur spécifique dont vous avez besoin pour un

champ n'est pas encore définie. Par exemple, vous pourriez avoir une table

CATEGORIES dans une base de données School Scheduling qui ne contient

actuellement pas de catégorie pour un nouvel ensemble de cours que vous

souhaitez proposer à partir de la session d'automne. Une autre raison pour

laquelle une table peut contenir des valeurs inconnues est qu'elles sont

réellement inconnues. Reportez-vous à nouveauau tableau CLIENTS de la figure

3.3 et considérez l'enregistrement de Marvin Russo. Supposons que vous

saisissez les données de M. Russo et que vous lui demandez le nom du comté

dans lequel il vit. S'il ne connaît pas le nom du comté et que vous ne

connaissez pas le comté qui comprend la ville dans lequel il vit, alors la valeur

du champ du comté dans son dossier est vraiment inconnue et est représentée

dansl'enregistrement comme Null. Évidemment, vous pouvez corriger le

problème une fois que l’un de vous a déterminé le nom correct du comté.

Une valeur de champ peut également être Null si aucune de ses valeurs ne

s'applique à un enregistrement particulier. Supposons un instant que vous

travaillez avec une table EMPLOYEES qui contient un champ SALARY et un

champ HOURLYRATE. La valeur de l'une de ces deux colonnes sera toujours

nulle car un employé ne peut pas percevoir à la fois un salaire fixe et un taux

horaire.
Il est important de noter qu’il existe une très mince différence entre « ne

s’applique pas » et « n’est pas applicable ». Dans l’exemple précédent, la

valeur de l’un des deux champs ne s’applique littéralement pas. Supposons

maintenant que vous travaillez avec une table PATIENTS qui contient un champ

appelé HAIRCOLOR et que vous mettez actuellement à jour un enregistrement

pour un patient de sexe masculin existant. Si ce patient est récemment devenu

chauve, alors la valeur de ce champ est définitivement « non applicable ». Bien

que vous puissiez simplement utiliser Null pour représenter une valeur qui n'est

pas applicable, je vous recommande toujours d'utiliser une vraie valeur telle

que « N/A » ou « Non applicable ». Cela rendra les informations plus claires à

long terme.

Comme vous pouvez le constater, l'autorisation ou non des valeurs nulles dans

un tableau dépend de la manière dont vous utilisez les données. Maintenant

que vous avez vu le côté positif de l’utilisation de Null, examinons les

implications négatives de son utilisation.

Le problème avec Null

L’inconvénient majeur de Null est qu’il a un effet néfaste sur les opérations

mathématiques. Une opération impliquant un NULL évalue à Null. Cela est

logiquement raisonnable : si un nombre est inconnu, alors le résultat de

l’opération est nécessairement inconnu. Notez comment une valeur Null

modifie le résultat de l'opération dans l'exemple suivant :

(25 × 3) + 4 = 79

(Nul × 3) + 4 = Nul

(25 × nul) + 4 = nul

(25 × 3) + Nul = Nul

Le tableau PRODUITS de la figure 3.4 permet d'illustrer les effets de Null sur les

expressions mathématiques qui incorporent les champs d'une table. Dans ce

cas, la valeur du champ VALEUR TOTALE est dérivée de l'expression

mathématique « [SRP] * [QTY ON HAND] ». Lorsque vous inspectez les

enregistrements de cette table, notez que la valeur du champ VALEUR TOTALE

est manquante là où la valeur QTY ON HAND est Null, ce qui entraîne

également Null pour le champ VALEUR TOTALE. Cela conduit à une grave

erreur non détectée qui se produit lorsque toutes les valeurs du champ VALEUR

TOTALE sont additionnées : un total inexact. Cette erreur est « non détectée »

car un programme SGBDR ne vous avertira pas automatiquement de

l'erreur. La seule façon d'éviter ce problème est de garantir que les valeurs du

champ QTY ON HAND ne peuvent pas être nulles.

Figure 3.4 Les valeurs nulles dans ce tableau auront un effet sur les
opérations mathématiques impliquant les champs du tableau.
La figure 3.5 permet d'illustrer l'effet de Null sur les fonctions d'agrégation qui

incorporent les valeurs d'un champ donné dans une table. Le résultat d'une

fonction d'agrégation, telle que COUNT(< fieldname >), sera Null s'il est basé

sur un champ contenant Null. Le tableau de la figure 3.5 montre les résultats

d'une requête récapitulative qui compte le nombre total d'occurrences de

chaque catégorie dans la table PRODUITS de la figure 3.4 . La valeur du champ

TOTAL OCCURRENCES est le résultat de l'expression de fonction

COUNT([CATEGORY]). Notez que la requête récapitulative affiche « 0 »

occurrences d’une catégorie non spécifiée, ce qui implique qu’une catégorie a

été attribuée à chaque produit. Cette information est clairement inexacte car

deux produits de la table PRODUITS n'ont pas été affectés à une catégorie.

Figure 3.5 Null affecte les résultats d'une fonction d'agrégation dans une
requête récapitulative.

Les problèmes de valeurs manquantes, de valeurs inconnues et de savoir si

une valeur sera utilisée dans une expression mathématique ou une fonction

d'agrégation sont tous pris en compte dans le processus de conception de la

base de données, et nous reviendrons et discuterons plus en détail de ces

problèmes dans le chapitre 8 , « Clés » . », Chapitre 9 , « Spécifications des

champs » et Chapitre 12 , « Vues ».

Termes liés à la structure

Tableau

Selon le modèle relationnel, les données d'une base de données relationnelle

sont stockées dans des relations qui sont perçues par l'utilisateur comme des

tables . Chaque relation est composée de tuples (enregistrements)

et d'attributs (champs). La figure 3.6 montre une structure de table typique.

Figure 3.6 Une structure de table typique.

Les tableaux sont les principales structures de la base de données et chaque

tableau représente toujours un sujet unique et spécifique. L'ordre logique des

enregistrements et des champs dans une table n'a absolument aucune

importance et chaque table contient au moins un champ, appelé

clé primaire, qui identifie de manière unique chacun de ses

enregistrements. (Dans la figure 3.6 , par exemple, CLIENT ID est la clé

primaire de la table CLIENTS.) En fait, les données d'une base de données

relationnelle peuvent exister indépendamment de la façon dont elles sont

physiquement stockées dans l'ordinateur en raison de ces deux dernières

caractéristiques de la table. C'est une excellente nouvelle pour l'utilisateur car

il n'a pas besoin de connaître l'emplacement physique d'un enregistrement

pour récupérer ses données.

Le sujet représenté par une table donnée peut être soit un objet , soit un

événement . Lorsque le sujet est un objet, cela signifie que la table représente
quelque chose de tangible, comme une personne, un lieu ou une chose. Quel

que soit son type, chaque objet possède des caractéristiques que vous pouvez

stocker sous forme de données puis traiter sous forme d'informations d'un

nombre presque infini de façons. Les pilotes, les produits, les machines, les

étudiants, les bâtiments et les équipements sont autant d'exemples d'objets

qu'un tableau peut représenter, et la figure 3.6 illustre l'un des exemples les

plus courants de ce type de tableau.

Lorsque le sujet d'un tableau est un événement, cela signifie que le tableau

représente quelque chose qui se produit à un moment donné et qui présente

les caractéristiques que vous souhaitez enregistrer. Vous pouvez stocker ces

caractéristiques sous forme de données, puis les traiter en tant qu'informations

exactement de la même manière qu'un tableau représentant un objet

spécifique. Parmi les exemples d'événements que vous devrez peut-être

enregistrer figurent les audiences judiciaires, les tournages de films, les

élections et les études géologiques. La figure 3.7 montre un exemple de

tableau représentant un événement que nous avons tous vécu à un moment ou

à un autre : un rendez-vous chez le médecin.

Une table qui stocke les données utilisées pour fournir des informations est

appelée table de données et constitue le type de table le plus courant dans une

base de données relationnelle. Les données de ce type de tableau sont

dynamiques car vous pouvez les manipuler (modifier, supprimer, etc.) et les

transformer en informations d'une manière ou d'une autre. Vous interagirez

constamment avec ces types de tables lorsque vous travaillerez avec votre

base de données.
Figure 3.7 Un tableau représentant un événement.

En revanche, une table de validation (également appelée table de recherche )

stocke les données que vous utilisez spécifiquement pour mettre en œuvre
l'intégrité des données. Un tableau de validation représente généralement des
sujets tels que les noms de villes, les catégories de compétences, les codes de

produits et les numéros d'identification du projet. Les données de ce type de

tableau sont statiques car elles changeront très rarement. Bien que vous ayez

très peu d'interaction directe avec ces tables, vous les utiliserez

fréquemment indirectement pour valider les valeurs que vous entrez dans une

table de données. La figure 3.8 montre un exemple de table de validation.

Figure 3.8 Un exemple de table de validation.

Je discute des tables de validation plus en détail au chapitre 11 , « Règles

métier ».
Champ

Un champ (appelé attribut dans la théorie des bases de données relationnelles)

est la plus petite structure de la base de données et représente une

caractéristique du sujet de la table à laquelle il appartient. Les champs sont les

structures qui stockent réellement les données. Les données de ces champs

peuvent ensuite être récupérées et présentées sous forme d'informations dans

presque toutes les configurations imaginables. La qualité des informations que

vous obtenez à partir de vos données est directement proportionnelle au temps

que vous consacrez à garantir l'intégrité structurelle et l'intégrité des données

des champs eux-mêmes. Il n’y a tout simplement aucun moyen de sous-

estimer l’importance des champs.

Chaque champ d'une base de données correctement conçue contient une et

une seule valeur, et son nom identifiera le type de valeur qu'il détient. Cela

rend la saisie des données dans un champ très intuitive. Si vous voyez des

champs avec des noms tels que FIRSTNAME, LASTNAME, CITY, STATE et

ZIPCODE, vous savez exactement quel type de valeurs doit être contenu dans

chaque champ. Il vous sera également très facile de trier les données par État

ou de rechercher toutes les personnes dont le nom de famille est

« Hernandez ».

Vous rencontrerez généralement trois autres types de champs dans une base

de données mal conçue ou mal conçue.

1. Un champ en plusieurs parties (également appelé champ composite ), qui

contient au moins deux éléments distincts dans sa valeur.

2. Un champ à plusieurs valeurs , qui contient plusieurs instances

du même type de valeur.

3. Un champ calculé , qui contient une valeur de texte concaténée ou le

résultat d'une expression mathématique.

La figure 3.9 montre un tableau avec un exemple de chacun de ces types de

champs.

Figure 3.9 Une table contenant des champs réguliers, calculés, en plusieurs
parties et à plusieurs valeurs.

Je couvre plus en détail les champs calculés, à plusieurs parties et à valeurs

multiples dans le chapitre 7 , « Établir des structures de table ».

Enregistrer

Un enregistrement (appelé tuple dans la théorie des bases de données

relationnelles) représente une instance unique du sujet d'une table. Il est

composé de l'ensemble des champs d'une table, que les champs contiennent

ou non des valeurs. En raison de la manière dont une table est définie, chaque

enregistrement est identifié dans la base de données par une valeur unique

dans le champ de clé primaire de cet enregistrement.

Dans la figure 3.9 , chaque enregistrement représente un client unique dans la

table, et le champ ID CLIENT identifiera un client donné dans la base de

données. À son tour, chaque enregistrement comprend tous les champs du

tableau et chaque champ décrit un aspect du client représenté par

l'enregistrement. Prenons par exemple le record de Sara Castilleja. Son

enregistrement représente une instance unique du sujet de la table

(« Clients ») et inclut l'ensemble des champs de la table, traités comme une

unité. Les valeurs de ces champs représentent des faits pertinents sur Mme

Castilleja qui sont importants pour quelqu'un dans l'organisation.

Les enregistrements sont un facteur clé pour comprendre les relations entre les

tables, car vous devez savoir comment un enregistrement d'une table est lié

aux autres enregistrements d'une autre table.

Voir

Une vue est une table « virtuelle » composée de champs provenant d'une ou

plusieurs tables de la base de données ; les tables qui composent la vue sont

appelées tables de base . Le modèle relationnel qualifie une vue de « virtuelle

» car elle extrait des données de tables de base plutôt que de stocker des

données seules. En fait, la seule information sur une vue stockée dans la base

de données est sa structure. De nombreux programmes SGBDR majeurs

prennent en charge les vues et les appellent généralement requêtes

enregistrées . Votre programme SGBDR spécifique déterminera si les vues sont

prises en charge et si vous faites référence à cet objet en tant que requête ou

vue.
Les vues vous permettent de voir les informations de votre base de données

sous de nombreux aspects différents, vous offrant ainsi une grande flexibilité

lorsque vous travaillez avec vos données. Vous pouvez créer des vues de

différentes manières, et elles sont particulièrement utiles lorsque vous les

basez sur plusieurs tables liées. Dans une base de données de planification

scolaire, par exemple, vous pouvez créer une vue qui consolide les données

des tables STUDENTS, CLASSES et CLASS SCHEDULES.

La figure 3.10 montre une vue appelée AFFECTATIONS D'INSTRUMENTS

composée de champs extraits des tables ÉTUDIANTS, INSTRUMENTS et

INSTRUMENTS ÉTUDIANTS. La vue affiche les données qu'elle extrait

simultanément de toutes ces tables, en fonction des valeurs correspondantes

entre les champs STUDENT ID des tables STUDENTS et STUDENT INSTRUMENTS

et les champs INSTRUMENT ID des tables INSTRUMENTS et STUDENT

INSTRUMENTS.
Figure 3.10 Un exemple de vue typique.

Il y a trois raisons principales pour lesquelles les opinions sont importantes.

1. Ils vous permettent de travailler simultanément avec les données de

plusieurs tables. (Pour qu'une vue fasse cela, les tables doivent avoir des

connexions, ou des relations , les unes avec les autres.)

2. Ils vous permettent d'empêcher certains utilisateurs de visualiser ou de

manipuler des champs spécifiques au sein d'une table ou d'un groupe de

tables. Cette capacité peut être très avantageuse en termes de sécurité.

3. Vous pouvez les utiliser pour mettre en œuvre l'intégrité des données. Une

vue que vous utilisez à cette fin est appelée vue de validation .

Vous en apprendrez davantage sur la conception et l'utilisation des vues

au chapitre 12 , « Vues ».

Note

Bien que tous les principaux fournisseurs de bases de données prennent en

charge le type de vue que j'ai décrit dans cette section, plusieurs fournisseurs

prennent en charge ce que l'on appelle

une vue indexée (ou matérialisée ). Une vue indexée est différente d'une vue

« normale » dans le sens où elle stocke des données et vous pouvez indexer

ses champs pour améliorer la vitesse à laquelle le SGBDR traite les données de

la vue. Une discussion complète sur les vues indexées dépasse le cadre de ce

livre car il s'agit d'un problème d'implémentation spécifique au

fournisseur. Toutefois, vous devez approfondir vos recherches sur ce sujet si

vous travaillez avec un logiciel SGBDR tel qu'Oracle, Microsoft SQL Server, IBM

DB2 ou Sybase SQL, ou si vous travaillez avec un entrepôt de données ou une

base de données de traitement analytique en ligne (OLAP).

Clés

Les clés sont des champs spéciaux qui jouent des rôles très spécifiques dans

une table, et le type de clé détermine son objectif dans la table. Il existe

plusieurs types de clés qu'une table peut contenir, mais les deux plus

importantes sont la clé primaire et la clé étrangère .

Une clé primaire est un champ ou un groupe de champs qui identifie de

manière unique chaque enregistrement dans une table ; une clé primaire

composée de deux champs ou plus est appelée clé primaire composite . La clé

primaire est absolument la clé la plus importante de tout le tableau.

• Une valeur de clé primaire identifie un enregistrement spécifique dans

l'ensemble de la base de données,

• Le champ de clé primaire identifie une table donnée dans l'ensemble de la

base de données.

• La clé primaire renforce l'intégrité au niveau de la table et permet d'établir

des relations avec d'autres tables de la base de données. (Vous en

apprendrez davantage sur les relations dans la section suivante.)

Chaque table de votre base de données doit avoir une clé primaire !

Le champ AGENT ID de la figure 3.11 est un bon exemple de clé primaire. Il

identifie de manière unique chaque agent dans la table AGENTS et contribue à

garantir l'intégrité au niveau de la table en garantissant l'absence de

duplication des enregistrements. Il établit également des relations entre la

table AGENTS et d'autres tables de la base de données, comme dans le cas de

la table ENTERTAINERS présentée dans l'exemple.

Figure 3.11 Un exemple de champs de clé primaire et étrangère.

Lorsque vous déterminez que deux tables entretiennent une relation l'une avec

l'autre, vous établissez généralement cette relation en prenant une copie de la

clé primaire de la première table et en l'incorporant dans la structure de la

deuxième table, où elle devient une clé étrangère . Le nom « clé étrangère »

est dérivé du fait que la deuxième table possède déjà sa propre clé primaire et

que la clé primaire que vous introduisez à partir de la première table est «

étrangère » à la deuxième table.

La figure 3.11 montre également un bon exemple de clé étrangère. Notez que

AGENT ID est la clé primaire de la table AGENTS et une clé étrangère dans la

table ENTERTAINERS. AGENT ID assume ce rôle car la table ENTERTAINERS

possède déjà une clé primaire : ENTERTAINER ID. En tant que tel, AGENT ID

établit la relation entre les deux tables.

En plus d'aider à établir des relations entre des paires de tables, les clés

étrangères aident également à mettre en œuvre et à garantir l'intégrité au

niveau des relations. Cela signifie que les enregistrements des deux tables

seront toujours correctement liés car les valeurs d'une clé

étrangère doivent correspondre aux valeurs existantes de la clé primaire à

laquelle elle fait référence. L’intégrité au niveau relationnel vous aide

également à éviter le redoutable enregistrement « orphelin », dont un exemple

classique est un enregistrement de commande sans client associé. Si vous ne

savez pas qui a passé la commande, vous ne pouvez pas la traiter, et vous ne

pouvez évidemment pas la facturer. Cela va gâcher vos ventes trimestrielles !

Les champs clés jouent un rôle important dans une base de données

relationnelle et vous devez apprendre à les créer et à les utiliser. Vous en

apprendrez davantage sur les clés primaires dans les chapitres 8 , « Clés »

et 10 , « Relations entre les tables ».

Indice

Un index est une structure fournie par un SGBDR pour améliorer le traitement

des données. Votre programme SGBDR particulier déterminera le

fonctionnement de l'index et la manière dont vous l'utilisez. Cependant, un

index n’a absolument rien à voir avec la structure logique d’une base de
données ! La seule raison pour laquelle j'inclus le terme index dans ce chapitre
est que les gens le confondent souvent avec le terme clé .
Index et clé ne sont que deux autres termes largement et fréquemment utilisés
à mauvais escient dans le secteur des bases de données et dans de

nombreuses publications et sites Web liés aux bases de données. (Vous vous

souvenez de mes commentaires sur les données et les informations ?) Vous

saurez toujours la différence entre les deux si vous vous souvenez que les clés

sont des structures logiques que vous utilisez pour identifier les

enregistrements dans une table et que les index sont des structures

physiques que vous utilisez pour optimiser le traitement des données.

Conditions liées aux relations

Des relations

Une relation existe entre deux tables lorsque l'on peut d'une manière ou d'une

autre associer les enregistrements de la première table à ceux de la

seconde. Toipeut établir la relation via un ensemble de clés primaires et

étrangères (comme vous l'avez appris dans la section précédente) ou via une

troisième table appelée table de liaison (également

appelée table associative ). La manière dont vous établissez la relation dépend

réellement du type de relation qui existe entre les tables. (Vous en apprendrez

plus à ce sujet dans un instant.) La figure 3.11 illustre une relation établie via

des clés primaires/étrangères, et la figure 3.12 illustre une relation établie avec

une table de liaison.

Figure 3.12 Relation établie entre deux tables à l'aide d'une table de liaison.

Une relation est un élément important d'une base de données relationnelle.

• Il vous permet de créer des vues multitables.

• Il est crucial pour l’intégrité des données car il permet de réduire les

données redondantes et d’éliminer les données en double.

Vous pouvez caractériser chaque relation de trois manières : par le type de

relation qui existe entre les tables, la manière dont chaque table participe et le

degré de participation de chaque table.

Types de relations

Trois types spécifiques de relations (traditionnellement appelés cardinalité )

peuvent exister entre une paire de tables : un-à-un , un-à-

plusieurs et plusieurs-à-plusieurs .

Relations individuelles

Une paire de tables entretient une relation biunivoque lorsqu'un seul

enregistrement de la première table est lié à zéro ou à un et un seul

enregistrement de la deuxième table, et qu'un seul enregistrement de

la deuxième table est lié à un et un seul. enregistrer dans le premier

tableau. Dans ce type de relation, une table sert de table « parent » et l’autre

sert de table « enfant ». Vous établissez la relation en prenant une copie de la

clé primaire de la table parent et en l'incorporant dans la structure de la table

enfant, où elle devient une clé étrangère. Il s'agit d'un type particulier de

relation car c'est la seule dans laquelle les deux tables peuvent réellement

partager la même clé primaire.

La figure 3.13 montre un exemple de relation un-à-un typique. Dans ce cas,

EMPLOYEES est la table parent et COMPENSATION est la table enfant. La

relation entre ces tables est telle qu'un seul enregistrement de la table

EMPLOYEES peut être lié à zéro ou à un seul enregistrement de la table

COMPENSATION, et qu'un seul enregistrement de la table COMPENSATION peut

être lié à un seul enregistrement de la table EMPLOYEES. Notez que EMPLOYEE

ID est bien la clé primaire dans les deux tables. Cependant, elle jouera

également le rôle de clé étrangère dans la table enfant.

Figure 3.13 Un exemple de relation un-à-un.

Relations un-à-plusieurs

Une relation un-à-plusieurs existe entre une paire de tables lorsqu'un seul

enregistrement de la première table peut être lié à zéro, un ou plusieurs

enregistrements de la deuxième table, mais qu'un seul enregistrement de

la deuxième table peut être lié uniquement à un enregistrement dans la

première table. Le modèle parent/enfant que j’ai utilisé pour décrire une

relation individuelle fonctionne également ici. Dans ce cas, la table du côté «

un » de la relation est la table parent et la table du côté « plusieurs » est la

table enfant. Vous établissez une relation un-à-plusieurs en prenant une copie

de la clé primaire de la table parent et en l'incorporant dans la structure de la

table enfant, où elle devient une clé étrangère.

L'exemple de la figure 3.14 illustre une relation un-à-plusieurs typique. Un seul

enregistrement de la table AGENTS peut être lié à un ou plusieurs

enregistrements de la table ENTERTAINERS, mais un seul enregistrement de la

table ENTERTAINERS n'est lié qu'à un seul enregistrement de la table

AGENTS. Comme vous l'avez probablement déjà deviné, AGENT ID est une clé

étrangère dans la table ENTERTAINERS.

Figure 3.14 Un exemple de relation un-à-plusieurs.

Il s’agit de loin de la relation la plus courante qui existe entre une paire de

tables dans une base de données. C’est crucial du point de vue de l’intégrité

des données, car cela permet d’éliminer les données en double et de maintenir

les données redondantes au minimum absolu. Vous en apprendrez davantage à

ce sujet à mesure que nous approfondirons le processus de conception.

Relations plusieurs-à-plusieurs

Une paire de tables entretient une relation plusieurs-à-plusieurs lorsqu'un seul

enregistrement de la première table peut être lié à zéro, un ou plusieurs

enregistrements de la deuxième table et que de même, un seul enregistrement

de la deuxième table peut être lié à zéro. un ou plusieurs enregistrements dans

la première table. Vous établissez cette relation avec une table de

liaison . (Vous en avez appris un peu plus sur ce type de tableau au début de
cette section.) Une table de liaison vous permet d'associer facilement les

enregistrements d'une table à ceux de l'autre et vous aidera à vous assurer

que vous n'aurez aucun problème à ajouter, supprimer , ou en modifiant les

données associées. Vous définissez une table de liaison en prenant des

copiesde la clé primaire de chaque table dans la relation et en les utilisant pour

former la structure de la nouvelle table. Ces champs remplissent en réalité

deux rôles distincts : ensemble, ils forment la clé primaire composite de la

table de liaison ; séparément, ils servent chacun de clé étrangère.

Une relation plusieurs-à-plusieurs qui n’est pas correctement établie est « non

résolue ». La figure 3.15 montre un exemple classique et clair de relation

plusieurs-à-plusieurs non résolue. Dans ce cas, un seul enregistrement de la

table STUDENTS peut être lié à plusieurs enregistrements de la table CLASSES,

et un seul enregistrement de la table CLASSES peut être lié

à plusieurs enregistrements de la table STUDENTS.

Figure 3.15 Un exemple de relation plusieurs-à-plusieurs non résolue.

Cette relation n’est pas résolue en raison de la particularité inhérente à la

relation plusieurs-à-plusieurs. Le problème principal est le suivant : comment

associer facilement les enregistrements de la première table aux

enregistrements de la deuxième table ? Pour reformuler la question à l'aide des

tableaux présentés dans la figure 3.15 , comment associer un seul élève à

plusieurs classes ou une classe spécifique à plusieurs élèves ? Insérez-vous

quelques champs ÉTUDIANTSdans le tableau CLASSES ? Ou ajoutez-vous

plusieurs champs CLASS à la table STUDENTS ? L'une ou l'autre de ces

approches rendra difficile l'utilisation des données de ces tableaux et affectera

négativement l'intégrité des données. La meilleure approche à adopter

consiste à créer et à utiliser une table de liaison, qui résoudra la relation

plusieurs-à-plusieurs de la manière la plus appropriée et la plus efficace. La

figure 3.16 montre cette solution en pratique.

Figure 3.16 Résolution de la relation plusieurs-à-plusieurs avec une table de
liaison.

Il est important que vous connaissiez le type de relation qui existe entre une

paire de tables, car il détermine la manière dont les tables sont liées, si les

enregistrements entre les tables sont interdépendants ou non, ainsi que le

nombre minimum et maximum d'enregistrements liés pouvant exister dans la

relation. Vous en apprendrez beaucoup plus sur les relations au chapitre 10 .

Types de participation

La participation d'une table au sein d'une relation peut être soit obligatoire ,

soit facultative . Supposons qu'une relation existe entre deux tables appelées

TABLE_A et TABLE_B.
• La participation de TABLE_A est obligatoire si vous devez saisir au moins

un enregistrement dans TABLE_A avant de pouvoir saisir des

enregistrements dans TABLE_B.

• La participation de TABLE_A est facultative si vous n'êtes pas obligé de

saisir des enregistrements dans TABLE_A avant de pouvoir saisir des

enregistrements dans TABLE_B.

Jetons un coup d'œil à un exemple utilisant les tables AGENTS et CLIENTS de la

figure 3.17 . La table AGENTS a une participation obligatoire au sein de la

relation si un agent doit exister avant que vous puissiez saisir un nouveau
client dans la table CLIENTS. Cependant, la participation à la table AGENTS

est facultative s'il n'est pas nécessaire qu'un agent existe dans la table avant

de saisir un nouveau client dans la table CLIENTS. Vous pouvez identifier le

type de participation approprié pour la table AGENTS en déterminant comment

vous allez utiliser ses données par rapport aux données de la table

CLIENTS. Par exemple, lorsque vous souhaitez vous assurer que chaque client

est affecté à un agent disponible, vous rendez obligatoire la participation de la

table AGENTS au sein de la relation.

Figure 3.17 Les tables AGENTS et CLIENTS.

Degré de participation

Le degré de participation détermine le nombre minimum d'enregistrements

qu'une table donnée doit avoir associés à un seul enregistrement dans la table

associée, et le nombre maximum d'enregistrements qu'une table donnée est

autorisée à associer à un seul enregistrement dans la table associée.

Considérons, encore une fois, une relation entre deux tables appelées TABLE_A

et TABLE_B. Vous établissez le degré de participation pour TABLE_B en

indiquant un nombre minimum et maximum d'enregistrements dans TABLE_B

qui peuvent être liés à un seul enregistrement dans TABLE_A. Si un seul

enregistrement dans TABLE_A peut être lié à pas moins de 1 mais pas plus de

10 enregistrements dans TABLE_B, alors le degré de participation pour TABLE_B

est de 1,10 . (La notation du degré de participation indique le nombre

minimum à gauche et le nombre maximum à droite, séparés par une virgule.)

Vous pouvez établir le degré de participation pour TABLE_A de la même

manière. Vous pouvez identifier le degré de participation de chaque table dans

une relation en déterminant la manière dont les données de chaque table sont

liées et comment vous utilisez les données.

Considérons à nouveau les tableaux AGENTS et CLIENTS de la figure 3.17 . Si

vous demandez à un agent de gérer au moins un client, mais certainement pas

plus de huit, alors le degré de participation pour la table

CLIENTSest 1,8 . Lorsque vous souhaitez vous assurer qu'un client ne peut être

affecté qu'à un seul agent, vous indiquez le degré de participation pour la table

AGENTS comme 1,1 . Vous apprendrez comment indiquer le degré de

participation pour une relation donnée au chapitre 10 .

Termes liés à l'intégrité

Spécification du champ

Une spécification de champ (traditionnellement appelée domaine ) représente

tous les éléments d'un champ. Chaque spécification de champ intègre trois

types d'éléments : généraux , physiques et logiques .

• Les éléments généraux constituent les informations les plus fondamentales

sur le champ et incluent des éléments tels que le nom du champ, la

description et la table parent.

• Les éléments physiques déterminent la façon dont un champ est construit et

comment il est représenté à la personne qui l'utilise. Cette catégorie

comprend des éléments tels que le type de données, la longueur et la prise

en charge des caractères.

• Les éléments logiques décrivent les valeurs stockées dans un champ et

incluent des éléments tels que la valeur requise, la plage de valeurs et la

prise en charge des valeurs nulles.

Vous apprendrez tous les éléments associés à une spécification de champ, y

compris ceux mentionnés ici, au chapitre 9 , « Spécifications de champ ».

Intégrité des données

L'intégrité des données fait référence à la validité, à la cohérence et à

l'exactitude des données dans une base de données. Je ne saurais trop insister

sur le fait que le niveau d’exactitude des informations que vous

récupérez de la base de données est directement proportionnel au

niveau d’intégrité des données que vous imposez à la base de

données. L'intégrité des données est l'un des aspects les plus importants

duprocessus de conception de base de données, et vous ne pouvez pas le

sous-estimer, le négliger ou même le négliger partiellement. Cela vous

exposerait au risque d’être en proie à des erreurs très difficiles à détecter ou à

identifier. En conséquence, vous prendriez des décisions importantes sur des

informations qui sont au mieux inexactes, ou au pire totalement invalides.

Il existe quatre types d'intégrité des données que vous mettrez en œuvre au

cours du processus de conception de base de données. Trois types d'intégrité

des données reposent sur divers aspects de la structure de la base de données

et sont étiquetés en fonction du domaine (niveau) dans lequel ils opèrent. Le

quatrième type d’intégrité des données repose sur la manière dont une

organisation perçoit et utilise ses données. Voici une brève description de

chacun :

1. L'intégrité au niveau de la table (traditionnellement connue sous le

nom d'intégrité d'entité ) garantit qu'aucun enregistrement en double

n'existe dans la table et que le champ qui identifie chaque enregistrement

dans la table est unique et jamais nul.

2. L'intégrité au niveau du champ (traditionnellement connue sous le

nom d'intégrité de domaine ) garantit que la structure de chaque champ est

solide ; que les valeurs de chaque champ sont valides, cohérentes et

exactes ; et que les champs du même type (tels que les champs CITY) sont

définis de manière cohérente dans toute la base de données.

3. L'intégrité au niveau relationnel (traditionnellement connue sous le

nom d'intégrité référentielle ) garantit que la relation entre une paire de

tables est solide et que les enregistrements des tables sont synchronisés

chaque fois que des données sont saisies, mises à jour ou supprimées de

l'une ou l'autre des tables.

4. Les règles métier imposent des restrictions ou des limitations sur certains

aspects d'une base de données en fonction de la manière dont une

organisation perçoit et utilise ses données. Ces restrictions peuvent affecter

certains aspects de la conception de la base de données, tels que la plage

et les types de valeurs stockées dans un champ, le type et le degré de

participation de chaque table au sein d'une relation, ainsi que le type de

participation.synchronisation utilisée pour l’intégrité au niveau des relations

dans certaines relations. Toutes ces restrictions sont abordées plus en détail

au chapitre 11 . Étant donné que les règles métier affectent l’intégrité, elles

doivent être prises en compte avec les trois autres types d’intégrité des

données lors du processus de conception.

Résumé

Ce chapitre a commencé par une explication de l'importance de la terminologie

pour définir, discuter ou lire sur le modèle de base de données relationnelle et

le processus de conception de base de données.

La section sur les termes liés à la valeur vous a montré qu'il existe une

différence distincte entre les données et les informations et que comprendre

cette différence est crucial pour comprendre le processus de conception de la

base de données. Vous en savez maintenant beaucoup sur Null et comment

cela affecte les informations que vous récupérez de la base de données.

Les termes liés à la structure ont ensuite été abordés et vous avez appris que
les structures de base de chaque base de données relationnelle sont les

champs , les enregistrements et les tables . Vous savez maintenant que les
vues sont des tables virtuelles utilisées, en partie, pour travailler
simultanément avec les données de deux ou plusieurs tables. Nous avons

ensuite examiné les champs clés , qui sont utilisés pour identifier les

enregistrements de manière unique au sein d'une table et pour établir une

relation entre une paire de tables. Enfin, vous avez appris la différence entre

un champ clé et un index . Vous savez désormais qu'un index est strictement

un dispositif logiciel (se manifestant sous la forme d'un fichier stocké sur

disque) utilisé pour optimiser le traitement des données.

Dans la section sur les termes liés aux relations , vous avez appris qu'une

connexion entre une paire de tables est appelée relation . Une relation est

utilisée pour garantir divers aspects de l'intégrité des données et constitue le

mécanisme utilisé par une vue pour extraire des données de plusieurs

tables. Vous avez ensuite découvert les trois caractéristiques des relations

entre tables : le type de relation (un-à-un, un-à-plusieurs, plusieurs-à-

plusieurs), le type de relation.participation (facultative ou obligatoire) et

le degré de participation (nombre minimum/maximum de dossiers associés).

Le chapitre s'est terminé par une discussion des termes liés à l'intégrité . Ici,

vous avez appris qu'une spécification de champ établit les caractéristiques

générales, physiques et logiques d'un champ, caractéristiques qui font partie

intégrante de chaque champ de la base de données. Vous avez ensuite appris

que l'intégrité des données est l'un des aspects les plus importants du

processus de conception d'une base de données en raison de son effet positif

sur les données de la base de données. De plus, vous savez désormais qu'il

existe quatre types d'intégrité des données : trois basés sur la structure de la

base de données et un basé sur la manière dont l'organisation interprète et

utilise ses données. Ces niveaux d'intégrité garantissent la qualité de la

conception de votre base de données et l'exactitude des informations que vous

en récupérez.

Questions de révision

1. Pourquoi la terminologie est-elle importante ?

2. Nommez les quatre catégories de termes.

3. Quelle est la différence entre données et informations ?

4. Que représente Null ?

5. Quel est l’inconvénient majeur de Null ?

6. Quelles sont les principales structures de la base de données ?

7. Nommez les trois types de tableaux.

8. Qu'est-ce qu'une vue ?

9. Indiquez la différence entre une clé et un index .

10. Quels sont les trois types de relations qui peuvent exister entre une paire

de tables ?

11. Quelles sont les trois manières dont vous pouvez caractériser une relation ?

12. Qu'est-ce qu'une spécification de terrain ?

13. Quels sont les trois types d’éléments qu’une spécification de champ

intègre ?

14. Qu'est-ce que l'intégrité des données ?

15. Nommez les quatre types d’intégrité des données.

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
Partie II : Le processus de conception
4. Aperçu conceptuel
5. Démarrage du processus
8h 33min restantes

Aperçu conceptuel

Je ne prétends pas comprendre l’Univers : il est bien plus grand que moi.

—THOMAS CARLYLE __

Sujets abordés dans ce chapitre

L’importance de terminer le processus de conception

Définir un énoncé de mission et des objectifs de mission

Analyse de la base de données actuelle

Création des structures de données

Détermination et établissement de relations entre tables

Détermination et définition des règles métier

Détermination et définition des vues

Examen de l'intégrité des données

Résumé

Questions de révision

Comprendre comment concevoir une base de données relationnelle n'est pas

aussi difficile que comprendre l'univers ; en fait, c'est beaucoup plus facile. Il

est cependant important que vous ayez une idée globale du fonctionnement du

processus de conception de base de données et une idée générale des étapes

impliquées dans le processus. Le but de ce chapitre est de fournir un aperçu du

processus de conception de base de données.

Pour les besoins de cet aperçu, j'ai regroupé toutes les techniques du processus

de conception en sept phases, et je discute de chaque phase dansConditions

générales. Cette discussion donne une bonne idée globale du processus de

conception de bases de données et j'espère qu'elle vous donnera une

compréhension beaucoup plus claire de chaque technique de conception

abordée dans cette partie du livre.

Vous pouvez utiliser la méthodologie de conception de ce livre pour concevoir

une nouvelle base de données entièrement à partir de zéro, affiner une base de

données existante ou vous aider à analyser une base de données existante afin

de pouvoir concevoir une nouvelle base de données basée sur les résultats de

votre analyse.

Note
Une base de données peut être conçue par une seule personne ou par une

équipe de conception composée de deux personnes ou plus. Dans le reste du

livre, j'utilise l'expression développeur de base de données et le

mot développeur pour désigner la personne ou le groupe qui conçoit la base de

données.

L’importance de terminer le processus de conception

Une chose que je veux préciser dès le début est l’importance de mener à bien

le processus de conception. On me demande souvent s’il est vraiment

nécessaire de suivre l’ensemble du processus de conception. Ma réponse est

toujours un « Oui ! » retentissant. On me demande ensuite si c'est encore

nécessaire si quelqu'un souhaite simplement créer une « simple » base de

données. ( Simple est l'un des mots les plus dangereux connus des

développeurs de bases de données. Rien n'est jamais « simple ».) Encore une

fois, ma réponse est : « Oui, c'est toujours nécessaire ». Le type, la taille ou

l’objectif de la base de données n’ont absolument aucun rapport avec l’intérêt

d’entreprendre une conception entièrement développée. Vous devez mettre en

œuvre et suivre le processus de conception de base de données du début à la

fin, quelle que soit la méthode de conception que vous utilisez.
Un fait bien connu et prouvé est que tenter de concevoir une base de données

sans recourir à un processus de conception de base de données approfondi est

une mauvaise chose.idée. De nombreux problèmes de base de données sont

causés par une mauvaise conception de la base de données, et

suivre partiellement le processus de conception est à peu près aussi grave que

de ne pas l'utiliser du tout. Une conception incomplète est une mauvaise

conception. Ce n'est que si vous suivez un processus de conception complet et

non abrégé que vous êtes assuré d'une structure solide et de l'intégrité des

données.

Un point important à garder à l’esprit est que le niveau d’intégrité structurelle

et d’intégrité des données de votre base de données est directement

proportionnel à la manière dont vous suivez minutieusement le processus de

conception. Moins vous consacrez de temps au processus de conception, plus

vous courez le risque de rencontrer des problèmes avec la base de

données. C’est aussi vrai aujourd’hui qu’il y a 25 ans. Suivre minutieusement le

processus de conception d’une base de données n’éliminera peut-être pas tous

les problèmes que vous pourriez rencontrer lors de la conception d’une base de

données, mais cela contribuera grandement à les minimiser. En travaillant avec

votre logiciel SGBDR, vous constaterez qu'une base de données bien conçue

est plus facile à mettre en œuvre qu'une base de données mal conçue.

Les bases de données ne sont pas difficiles à concevoir ; il faut juste un peu de

temps pour les concevoir correctement. Ne vous permettez pas de prendre des

raccourcis lorsqu'il vous semble que le processus de conception prend trop de

temps. Soyez simplement patient et rappelez-vous ce qu'un vieux sage a dit un

jour :

On n'a jamais le temps de bien faire les choses, mais il est toujours temps de

tout recommencer !
Définir un énoncé de mission et des objectifs de mission

La première phase du processus de conception de la base de données consiste

à définir un énoncé de mission et des objectifs de mission pour la base de

données. L'énoncé de mission établit l'objectif de la base de données et vous

fournit une orientation distincte pour votre travail de conception.

Chaque base de données est créée dans un but précis, qu'il s'agisse de

résoudre un problème commercial particulier, de gérer les transactions

quotidiennes deune entreprise ou une organisation, ou pour être utilisé dans le

cadre d’un système d’information. Vous identifiez l’objectif de votre base de

données et le définissez dans un énoncé de mission. Cela permettra de

garantir que vous développez une structure de base de données appropriée et

que vous collectez les données nécessaires pour prendre en charge l'objectif

prévu de la base de données.

Vous définirez également les objectifs de la mission au cours de cette phase. Il

s'agit d'instructions qui représentent les tâches générales que vos utilisateurs

peuvent effectuer sur les données de la base de données. Vous utilisez ces

objectifs pour soutenir votre énoncé de mission et pour vous aider à déterminer

divers aspects de la structure de la base de données.

Deux groupes distincts de personnes seront impliqués dans la définition de

l'énoncé de mission et des objectifs de la mission. Le premier groupe comprend

le développeur de la base de données (vous), la personne propriétaire de la

base de données et le personnel de direction ou la personne qui est finalement

responsable de la base de données ; ce groupe est chargé de définir l'énoncé

de mission. Le deuxième groupe comprend le développeur de la base de

données (encore vous), le personnel de direction ou la personne qui est

finalement responsable de la base de données, et les utilisateurs finaux ; ce

groupe est chargé de définir les objectifs de la mission.

 Note

J'utilise désormais le terme gestion pour désigner « le personnel de direction ou

la personne qui est finalement responsable de la base de données » par souci

de clarté et de concision.

Analyse de la base de données actuelle

La deuxième phase du processus de conception de base de données consiste à

analyser la base de données actuelle si elle existe. (C'est le scénario le plus

courant de nos jours.) En fonction de votre organisation, la base de données

sera généralement une base de données existante ou une base de données

papier . Une base de données héritée (également appelée base de

données héritée ) est une base de données qui a étéexiste et est utilisé depuis

plusieurs années. Une base de données papier, comme vous le savez peut-être

déjà, est une collection lâche de formulaires, de dossiers manille, etc. Il est

étrange de penser qu'au moment d'écrire ces lignes (mai 2020), un certain

nombre d'entreprises, d'organisations et d'agences gouvernementales utilisent

encore du papier dans le cadre de leurs processus de collecte de

données. Cependant, quel que soit le type ou l'état de la base de données, son

analyse fournira des informations précieuses sur la manière dont votre

organisation utilise et gère actuellement ses données. L'analyse implique

également de revoir la manière dont votre organisation collecte et présente

actuellement les données. Vous examinez comment votre organisation utilise

des formulaires et des rapports papier ou des applications de bureau pour

collecter et présenter des données. Enfin, vous tenez compte de la manière

dont votre organisation utilise ses données sur Internet et examinez toutes les

applications Web qui fonctionnent avec la base de données.

Une autre partie de l'analyse consiste à mener des entretiens avec les

utilisateurs et la direction pour identifier comment ils interagissent

quotidiennement avec la base de données. En tant que développeur de base

de données, vous demandez aux utilisateurs comment ils travaillent avec la

base de données et quels sont leurs besoins en informations à l'heure

actuelle. Vous interrogez ensuite le personnel de direction et lui posez des

questions sur les informations qu'il reçoit actuellement et sur sa perception des

besoins globaux en informations de l'organisation. Ces entretiens sont un

élément important de votre analyse car les questions que vous posez (ou ne

posez pas) auront un grand impact sur la structure finale de votre base de

données. Vous devez mener des entretiens complets de manière opportune,

pratique et efficace si vous souhaitez concevoir une base de données qui

répond réellement aux besoins d'information de votre organisation.

Ensuite, vous utilisez les informations que vous avez recueillies à partir de

l'analyse et des entretiens pour dresser une première liste de domaines. Vous

affinez ensuite cette liste en supprimant tous les champs calculés et en les

plaçant dans leur propre liste. Vous utiliserez ces champs calculés plus tard

dans le processus de conception. La liste affinée constitue les exigences

fondamentales en matière de données de votre organisation et constitue un

point de départ pour la conception d'une nouvelle base de données. (Comme

vous le savez, rien n'est jamais vraiment définitif. Soyez assuré que vous

élargirez et affinerez davantage cette liste de champs au fur et à mesure que

vous développerez votre conception.)

Une fois votre liste de champs initiale terminée, vous l'envoyez à vos

utilisateurs et à votre direction pour un bref examen et un éventuel

affinement. Vous encouragez les retours (du mieux possible) et prenez en

compte leurs suggestions de modifications. Si vous pensez que les suggestions

sont raisonnables et bien étayées, vous apportez les modifications appropriées,

enregistrez la liste dans son état actuel et passez à la phase suivante.

Création des structures de données

La création des structures de données pour la base de données constitue la

troisième phase du processus de conception de la base de données. Vous

définissez des tables et des champs, établissez des clés et définissez des

spécifications de champ pour chaque champ.

Les tables sont les premières structures que vous définissez dans la base de

données. Vous déterminez les différents sujets que les tableaux représenteront

à partir des objectifs de mission que vous avez compilés au cours de la

première phase du processus de conception et des exigences en matière de

données que vous avez recueillies au cours de la deuxième phase. Vous

établissez ensuite ces sujets sous forme de tables et les associez aux champs

de la liste de champs que vous avez compilée au cours de la deuxième phase

du processus de conception. Une fois cette tâche terminée, vous examinez

chaque tableau pour vous assurer qu'il ne représente qu'un seul sujet et qu'il

ne contient pas de champs en double.

Vous allez maintenant examiner les champs de chaque table. Vous affinez tous

les champs en plusieurs parties ou à plusieurs valeurs de la table afin qu'ils

stockent chacun une seule valeur, et vous déplacez ou supprimez les champs

qui ne représentent pas les caractéristiques distinctes du sujet représenté par

la table. Une fois cette révision terminée, vous examinez et affinez ensuite les

structures des tables. Cela implique de vérifier le travail que vous avez effectué

sur les champs pour vous assurer que vous n'avez rien oublié accidentellement

et de vous assurer que chaque structure de table est correctement

définie. Ensuite, vous établissez les clés appropriées pour chaque table. Votre

tâche principale est de vous assurer que chaque table possède une clé primaire

correctement définie ; cette clé particulière identifie de manière unique chaque

enregistrement dans une table.

La dernière étape de cette phase consiste à établir les spécifications de chaque

champ de la base de données. À ce stade, vous menez des entretiens avec les

utilisateurs et la direction pour vous aider à identifier les caractéristiques

spécifiques du domaine qui sont importantes pour eux et à examiner et

discuter de toutes les caractéristiques avec lesquelles ils pourraient ne pas être

familiers. Après avoir terminé ces entretiens, vous définissez et documentez les

spécifications de chaque domaine. Les structures de table sont maintenant

prêtes pour la phase suivante, une fois que vous avez effectué les

améliorations que vous avez identifiées lors de la révision.

Détermination et établissement de relations entre tables

La quatrième phase du processus de conception de base de données consiste à

établir des relations entre les tables. Vous menez à nouveau des entretiens

avec les utilisateurs et la direction, identifiez les relations, identifiez les

caractéristiques des relations et établissez l'intégrité au niveau des relations.

Travailler avec les utilisateurs et la direction est un exercice prudent car ils

peuvent vous aider à identifier les relations entre les données. Vous ne pouvez

pas connaître tous les aspects des données que votre organisation utilise. Il

vous sera donc très bénéfique de tirer parti des connaissances dont vous

disposez sur les données qu’elles utilisent.

Après avoir identifié les relations, vous établissez une connexion logique entre

les tables de chaque relation avec une clé primaire ou avec une table de

liaison. Ce que vous utilisez réellement dépend du type de relation que vous

établissez entre les tables. Ensuite, vous déterminez le type et le degré de

participation des tables dans chaque relation. Dans certains cas, ces

caractéristiques de participation vous seront évidentes en raison de la nature

des données stockées dans les tableaux. Dans d'autres cas, vous baserez les

caractéristiques de participation sur des règles métier spécifiques.

Détermination et définition des règles métier

La détermination et la définition des règles métier constituent la cinquième

phase du processus de conception de base de données. Au cours de cette

phase, vous mènerez des entretiens, identifierez les limites sur divers aspects

de la base de données, établirez des règles métier et définirez et

implémenterez des tables de validation.

La manière dont votre organisation visualise et utilise ses données déterminera

un ensemble de limitations et d'exigences que vous devez intégrer à la base de

données. Vos entretiens avec les utilisateurs et la direction vous aideront à

identifier les contraintes spécifiques que vous imposerez aux données, aux

structures de données ou aux relations. Vous documentez ensuite ces

spécifications sous forme de règles métier.

Les entretiens que vous mènerez avec les utilisateurs révéleront des

limites spécifiques sur divers aspects de la base de données. Par exemple, un

utilisateur travaillant avec une base de données de traitement des commandes

est très conscient de détails spécifiques, tels que le fait qu'une date

d'expédition doit être postérieure à une date de commande ; qu'il doit toujours

y avoir un numéro de téléphone de jour ; et qu'un mode d'expédition doit

toujours être indiqué. En revanche, vos entretiens avec la direction révèlent

des limites générales sur divers aspects de la base de données. Par exemple, le

chef de bureau d'une agence de divertissement connaît des problématiques

générales telles que le fait qu'un agent ne peut représenter plus de 20 artistes

et que les informations promotionnelles pour chaque artiste doivent être mises

à jour chaque année.

Ensuite, vous définissez et implémentez les tables de validation nécessaires

pour prendre en charge certaines règles métier. Supposons que vous constatiez

que certains champs ont une plage limitée de valeurs en raison de la manière

dont votre organisation les utilise. Vous pouvez utiliser des tables de validation

pour garantir la cohérence et la validité des valeurs stockées dans ces champs.

Le niveau d'intégrité établi par les règles métier à ce stade est important car il

est directement lié à la manière dont votre organisationconsulte et utilise ses

données. La perspective de l'organisation sur les données changera à mesure

que l'organisation se développe, ce qui signifie que les règles métier doivent

également changer. La détermination et l'établissement de règles

commerciales sont un processus continu et itératif, et vous devez faire preuve

de diligence constante si vous souhaitez maintenir correctement ce niveau

d'intégrité.
Détermination et définition des vues

La sixième phase du processus de conception consiste à déterminer et à définir

les vues. Ici, vous mènerez des entretiens (encore une fois), identifierez

différentes manières de travailler avec les données et établirez vos points de

vue.

Vous identifiez les types de vues que vous devez créer dans la base de

données en interrogeant les utilisateurs et la direction et en déterminant

comment ils travaillent avec leurs données respectives. Vous constaterez peut-

être, par exemple, que de nombreux utilisateurs ont besoin d'informations

détaillées pour effectuer leur travail, tandis que d'autres n'ont besoin que

d'informations récapitulatives pour les aider à prendre des décisions

stratégiques pour l'organisation. Chaque groupe d'utilisateurs doit accéder aux

informations de manière très spécifique et vous pouvez utiliser des vues pour

répondre à ces situations.

Ensuite, vous définissez les vues que vous avez identifiées au cours du

processus d'entretien à l'aide des tables et des champs appropriés et établissez

des critères pour ces vues qui sont requises pour récupérer des informations

spécifiques. Par exemple, vous établiriez des critères pour une vue qui doit

répertorier tous les clients situés au Texas ou pour une vue qui doit afficher le

nombre total de fournisseurs autorisés (par ville) à Washington.

Examen de l'intégrité des données

La septième et dernière phase du processus de conception de la base de

données consiste à examiner la structure finale de la base de données pour

vérifier l'intégrité des données.

Tout d’abord, vous examinez chaque table pour vous assurer qu’elle répond

aux critères d’une table correctement conçue et vérifiez la structure appropriée

des champs de chaque table. Vous résolvez ensuite les incohérences ou les

problèmes que vous rencontrez et révisez les structures une fois de plus. Vous

pouvez désormais vérifier que vos tables ont une intégrité au niveau des

tables.

Deuxièmement, vous examinez et vérifiez les spécifications de chaque

champ. Vous apportez les améliorations nécessaires aux champs, puis vérifiez

l'intégrité au niveau du champ. Cet examen réaffirme l'intégrité au niveau du

terrain que vous avez identifiée et établie plus tôt dans le processus de

conception de la base de données.

Troisièmement, vous examinez la validité de chaque relation, confirmez le type

de relation et confirmez les caractéristiques de participation pour chaque table

de la relation. Vous examinez ensuite l'intégrité de la relation pour vous assurer

qu'il existe des valeurs correspondantes entre les champs partagés et qu'aucun

problème ne se produit lors de l'insertion, de la mise à jour ou de la

suppression de données dans l'une des tables de la relation.

Enfin, vous passez en revue les règles métier que vous avez identifiées plus tôt

dans le processus de conception de base de données et confirmez les

contraintes que vous avez imposées sur différents aspects de la base de

données. Si d'autres limitations ont été portées à votre attention depuis la

dernière série d'entretiens avec le personnel, vous les établissez en tant que

nouvelles règles métier et vous les ajoutez à l'ensemble de règles métier

existant.
Vous êtes prêt à implémenter votre structure de base de données logique dans

un programme SGBDR après avoir terminé l'intégralité du processus de

conception de base de données. Cependant, le processus n’est

jamais vraiment terminé car la structure de la base de données devra toujours

être affinée à mesure que votre organisation évolue.

Résumé

Nous avons commencé ce chapitre par une discussion sur l'importance de

mener à bien le processus de conception, et vous avez appris que concevoir

une base de données sans bénéficier d'une bonne méthode de conception

conduit à une conception médiocre et inappropriée. Nous avons également

discuté du fait que le niveau d’intégrité structurelle et des données est

directement proportionnel à la manière dont vous suivez minutieusement le

processus de conception. Vous avez ensuite appris que les données

incohérentes et les informations inexactes sont deux problèmes généralement

associés aux bases de données mal conçues.

Nous avons ensuite examiné un aperçu de l'ensemble du processus de

conception de base de données. Le processus a été consolidé dans les phases

suivantes pour vous fournir une image claire des étapes générales impliquées

dans la conception d'une base de données.

1. Définir un énoncé de mission et des objectifs de mission pour la base de

données. L'énoncé de mission définit le but de la base de données et les

objectifs de la mission définissent les tâches qui doivent être effectuées par

les utilisateurs sur les données de la base de données.

2. Analysez la base de données actuelle. Vous identifiez les besoins en

données de votre organisation en examinant la manière dont votre

organisation collecte et présente actuellement ses données et en menant

des entretiens avec les utilisateurs et la direction pour déterminer comment

ils utilisent la base de données au quotidien.

3. Créez les structures de données. Vous établissez des tableaux en identifiant

les sujets que la base de données suivra. Ensuite, vous associez chaque

table à des champs qui représentent des caractéristiques distinctes du sujet

de la table et désignez un champ particulier (ou un groupe de champs)

comme clé primaire. Vous établissez ensuite les spécifications de champ

pour chaque champ de la table.

4. Déterminer et établir des relations entre les tables. Vous identifiez les

relations qui existent entre les tables de la base de données etétablissez la

connexion logique pour chaque relation à l'aide de clés primaires et de clés

étrangères ou à l'aide de tables de liaison. Ensuite, vous définissez les

caractéristiques appropriées pour chaque relation.

5. Déterminer et définir les règles métier. Vous menez des entretiens avec les

utilisateurs et la direction pour identifier les contraintes qui doivent être

imposées sur les données de la base de données. La manière dont votre

organisation visualise et utilise ses données détermine généralement les

types de contraintes que vous devez imposer à la base de données. Vous

déclarez ensuite ces contraintes sous forme de règles métier, et elles

serviront à établir différents niveaux d’intégrité des données.

6. Déterminer et établir des points de vue. Vous interrogez les utilisateurs et la

direction pour identifier les différentes manières dont ils travaillent avec les

données de la base de données. Une fois vos entretiens terminés, vous

établissez les points de vue appropriés. Vous définissez chaque vue à l'aide

des tables et des champs appropriés et établissez des critères pour les vues

qui doivent afficher un ensemble limité ou fini d'enregistrements.

7. Vérifiez l’intégrité des données. Cette phase comporte quatre étapes. Tout

d’abord, vous examinez chaque table pour vous assurer qu’elle répond aux

critères de conception appropriés. Deuxièmement, vous examinez et vérifiez

toutes les spécifications du champ. Troisièmement, vous testez la validité de

chaque relation. Quatrièmement, vous examinez et confirmez les règles

métier.

Questions de révision

1. Pourquoi est-il important de mener à bien le processus de conception ?

2. Vrai ou faux : Le niveau d’intégrité structurelle est directement proportionnel

à la façon dont vous suivez minutieusement le processus de conception.

3. Quel est le but d’un énoncé de mission ?

4. Quels sont les objectifs de la mission ?

5. Quelles sont les exigences fondamentales en matière de données de votre

organisation ?

6. Comment déterminez-vous les différents sujets que les tableaux

représenteront ?

7. Vrai ou faux : vous établissez les spécifications de champ pour chaque

champ de la base de données au cours de la deuxième phase du processus de

conception de la base de données.

8. Comment établir une connexion logique entre les tables dans une relation ?

9. Qu'est-ce qui détermine un ensemble de limitations et d'exigences que vous

devez intégrer à la base de données ?

10. Que pouvez-vous concevoir et mettre en œuvre pour prendre en charge

certaines règles métier ?

11. Comment déterminez-vous les types de vues que vous devez créer dans la

base de données ?

12. Quand pouvez-vous implémenter votre structure logique dans un

programme SGBDR ?

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
4. Aperçu conceptuel
5. Démarrage du processus
6. Analyse de la base de données actuelle
8h 33min restantes

Démarrage du processus

« Par où dois-je commencer, s'il vous plaît, Votre Majesté ? Il a demandé.

« Commencez par le début, dit gravement le roi, et continuez jusqu'à la fin :

puis arrêtez. »

—L EWIS C ARROLL

LES AVENTURES D' A LICE AU PAYS DES MERVEILLES

Sujets abordés dans ce chapitre

Mener des entretiens

Définir l'énoncé de mission

Définir les objectifs de la mission

Résumé

Questions de révision

Tout a un début et le processus de conception de base de données n’est pas

différent. Chose intéressante, vous démarrez le processus en définissant le

résultat final. C'est dès la toute première étape du processus de conception de

la base de données que vous identifiez et déclarez l'objectif de la base de

données. Vous définissez et déclarez également une liste des tâches que vos

utilisateurs peuvent effectuer sur les données de la base de données. Ces deux

éléments vous fournissent une orientation et une orientation pour le

développement d'une base de données et contribuent à garantir que la

structure finale de votre base de données prend en charge l'objectif et les

tâches déclarés.

Note spéciale

La pandémie de COVID-19 de 2020 a changé la façon dont les gens mènent

leurs affaires et la façon dont nous interagissons les uns avec les autres. Un

nombre bien plus important de personnes travaillent à distance, notamment à

domicile. De nombreuses entreprises permettaient déjà à leurs employés de

travailler à distance avant cela, et beaucoup utilisaient des plateformes de

réunion populaires pour organiser leurs réunions. Mais la pandémie n’a fait

qu’accélérer cette idée à une échelle bien plus grande. Au moment d’écrire ces

lignes, les grandes entreprises, organisations et agences gouvernementales

repensent leurs modèles de travail, et nombre d’entre elles conserveront

probablement l’idée du travail à distance, sous une forme ou une autre, comme

élément permanent de leur nouvelle façon de faire des affaires.

À la lumière de ces changements, j'ai ajusté ma discussion sur les entretiens en

conséquence. Mes conseils et directives abordent désormais les entretiens du

point de vue des réunions que vous êtes susceptible de mener sur des

plateformes de réunion telles que Skype, Zoom, Microsoft Teams ou Google

Meet. Comme toujours, je couvrirai uniquement les questions conceptuelles

des entretiens ; vous devrez vous référer au contenu d'aide ou aux vidéos «

Comment faire » de la plateforme que vous utilisez pour savoir comment

mener la réunion sur cette plateforme.

Mener des entretiens

Les entretiens font partie intégrante de la conception d’une base de données et

jouent un rôle clé lors de certaines phases du processus de conception. En

supposant que vous travaillez au sein d'une organisation et que vous devez

concevoir une base de données pour soutenir le travail que vous et vos

collègues effectuez, vous devez vous assurer que vous menez vos entretiens

de la manière décrite dans ce livre. Cela signifie que vous interagirez avec

certains de vos collègues, le personnel de direction et le propriétaire (selon la

taille de l'organisation) tout au long du processus de conception. Si vous

travaillez pour une petite organisation qui n'emploie qu'une poignée de

personnespersonnes ou si vous créez simplement une base de données pour

vous-même, vous réaliserez des « auto-entretiens » ; vous continuerez à mener

les entretiens décrits dans ce livre, mais vous agirez en tant

qu'intervieweur et personne interrogée. C'est vous qui apporterez les réponses

aux questions.

Note
L'entretien est une compétence que vous pouvez acquérir avec un peu de

patience, de diligence et de pratique. Vous pouvez utiliser diverses approches

et techniques pour mener un entretien, et de nombreux articles, articles et

livres universitaires sont disponibles sur le sujet. Une discussion approfondie de

ce sujet dépasse le cadre de ce livre, mais j'ai inclus dans ce chapitre plusieurs

techniques et lignes directrices qui vous aideront à mener vos entretiens de

manière efficace et efficiente.

Les entretiens sont importants car ils fournissent un lien de communication

précieux entre vous (le développeur) et les personnes pour lesquelles vous

concevez la base de données, contribuent à garantir le succès de vos efforts de

conception et fournissent des informations critiques qui peuvent affecter la

conception de la structure de la base de données. . Lorsque vous travaillez

avec des relations de table, par exemple, vous aurez peut-être du mal à

déterminer le type et le degré de participation pour quelques relations. La

seule façon pour vous de déterminer les valeurs appropriées pour ces

caractéristiques relationnelles est de mener un entretien avec les personnes

appropriées de votre organisation. Vous pouvez ensuite utiliser les informations

que vous avez recueillies lors de l'entretien pour définir les caractéristiques de

la relation. Vous pouvez utiliser un entretien comme outil de collecte

d'informations pour obtenir de nouvelles informations de la part des

participants concernant une partie de la base de données ou pour clarifier des

faits que vous ne comprenez pas. Notez que vous devez toujours mener

chacun des entretiens intégrés dans ce processus de conception, quel que soit

le type de base de données que vous concevez ou le nombre de personnes

impliquées. Vous manquerez inévitablement certaines informations

importantes lorsque vous négligez ou omettez l'un des entretiens, ce qui

pourrait nuire à la structure finale de votre base de données.

 Note

Dans les chapitres restants, j'utilise des questions ouvertes pour tous les

entretiens qui font partie du concept ou de la technique en discussion. Vous

pouvez utiliser ces questions comme guide pour formuler vos propres

questions pour un entretien donné.

Établissez toujours des lignes directrices pour vos entretiens avant de les

mener. Cela permet de garantir que vous menez vos entretiens de manière

cohérente et qu'ils sont toujours (ou généralement) réussis. Les sections

suivantes proposent quelques lignes directrices que vous pouvez établir pour

les participants et pour vous-même.

Lignes directrices pour les participants

• Faites prendre conscience aux participants de vos intentions. Beaucoup de

gens se méfient des entretiens. Ils n'aiment pas être « mis dans l'embarras

» et ils ne veulent pas qu'on leur pose ce qu'ils pensent être des questions «

pièges ». Faites savoir à chaque personne le sujet dont vous souhaitez

discuter, qui d’autre est susceptible de participer à la discussion, l’heure à

laquelle vous souhaitez commencer la session et si cet entretien fait partie

d’une série d’entretiens en cours. Toutes les personnes participant à une

séance d'entretien donnée sont plus susceptibles de s'engager dans la

conversation en cours et d'être très réactives à vos questions s'ils savent

comment vous allez mener la séance et ce que vous attendez

d'eux. Surtout, rassurez-les sur le fait que l’entretien n’est pas une

évaluation déguisée de leur performance ; vous voulez vous assurer qu’ils

se sentent à l’aise pour vous parler ouvertement et sans réserve. Cela

contribuera grandement à établir une base de confiance entre vous et les

participants.
• Faites savoir aux participants que vous appréciez leur participation à

l'entretien et que leurs réponses aux questions de l'entretiensont précieux

pour le projet de conception global. Les expériences antérieures sont
susceptibles de faire croire à certaines personnes que quelle que soit la

contribution qu’elles apportent au travail, elle passe inaperçue et sous-

estimée. Même lorsque leur contribution a eu un impact significatif sur un

projet spécifique, ils ont rarement reçu un simple « Merci ». À la lumière de

cela, il n’y a aucune réelle motivation pour eux de participer à votre

entretien. Beaucoup, sinon la totalité, de vos participants sont susceptibles

de commencer avec cette attitude, mais vous pouvez vraiment augmenter

leur motivation en leur faisant savoir que vous appréciez sincèrement et

honnêtement leur participation et que vous êtes très intéressé par leurs

réponses. Assurez-leur que leurs commentaires sont vraiment précieux pour

le processus de conception et que, dans de nombreux cas, leurs réponses

peuvent justifier et valider les décisions prises tout au long du processus de

conception. Les participants seront plus enclins à vous aider de toutes les

manières possibles si vous vous rendez crédible en étant véritablement

sincère ; votre travail sera beaucoup plus facile et tout le monde participera

volontairement et avec enthousiasme. Il est également très efficace de

montrer, lors d'un deuxième entretien, comment vous avez déjà utilisé les

contributions antérieures des participants.

• Assurez-vous que tout le monde comprend que vous êtes l'arbitre officiel en

cas de litige. Il est inévitable que des différends mineurs surgissent au cours
d'un entretien et qu'il y ait une certaine tension jusqu'à ce que ces

différends soient résolus. Vous pouvez éviter cette situation en arbitreant

vous-même ces litiges. En tant que développeur de bases de données, vous

êtes le mieux placé pour le faire car vous avez un point de vue objectif et

pouvez voir les deux côtés d’un problème. De plus, la décision que vous

prendrez sera toujours dans le meilleur intérêt de la structure de la base de

données. N'oubliez jamais que les litiges portant sur autre chose que la

structure de la base de données peuvent et doivent être soumis à une

autorité plus appropriée, si elle existe.

Lignes directrices pour les intervieweurs (celles-ci sont pour vous)

• Choisissez une plateforme de réunion appropriée pour mener votre

réunion. Quelques plateformes de réunion populaires que vous pouvez

utiliser pour mener votre réunion incluent Skype, Zoom, WebEx, Microsoft

Teams et Google Meet. Si vous travaillez dans une grande organisation, vous

devrez probablement utiliser celle qui constitue la norme

approuvée. L’avantage ici est que la plupart des gens l’ont probablement

utilisé à un moment donné et connaissent son fonctionnement. Si vous

faites partie d'une petite organisation ou si vous avez une petite entreprise,

choisissez la plateforme la plus susceptible d'être la plus intuitive et la plus

simple à utiliser pour votre public cible. C'est une idée particulièrement

intéressante si vous avez des personnes qui ne sont pas du tout familières

ou qui ne sont pas à l'aise avec ce type de plates-formes.

• Fixez une limite raisonnable et pratique pour le nombre de personnes

participant à chaque entretien. Limiter le nombre de participants favorise un

cadre plus détendu et vous permet d’encourager plus facilement tout le

monde à participer. L'un des problèmes que vous rencontrerez en menant

un entretien avec un grand nombre de personnes est que le niveau

d'intimidation de certains participants augmentera en proportion directe

avec le nombre de participants prenant part à l'entretien dans son

ensemble. Certaines personnes ont simplement peur de paraître ignorantes

ou incompétentes devant leurs collègues, même si de tels sentiments sont

réellement justifiés. Vous avez donc une très bonne raison de limiter le

nombre de participants à l’entretien.

• Mener des entretiens séparés pour les utilisateurs et la direction. Séparer

les deux groupes est une bonne idée pour diverses raisons, notamment le «

facteur de peur » que j’ai mentionné plus tôt. Principalement, vous

souhaitez les séparer parce que chaque groupe a une perspective différente

sur l'organisation dans son ensemble et sur la manière dont l'organisation

utilise ses données au quotidien. Mener des entretiens séparés pour chaque

groupe vous permet de tirer parti de leurs perspectives uniques pour

votreavantage lorsque vous travaillez dans le processus de conception de

base de données. Une autre raison de séparer les entretiens est d’éliminer

les conflits qui peuvent surgir lorsque ces groupes ne sont pas d’accord sur

certains aspects de l’organisation. Il est assez courant qu'il y ait un manque

de communication entre eux, et il y a 50/50 de chances que l'entretien fasse

remonter ce problème à la surface. Cela peut les inciter à établir de

meilleures lignes de communication, ou cela peut aggraver encore le

problème. Dans tous les cas, ce problème de communication peut

compliquer et prolonger votre entretien et diffuser ses résultats. Utilisez

votre connaissance de l’organisation pour vous aider à décider s’il convient

de séparer les entretiens. Si vous devez mener un entretien avec les deux

groupes en même temps, faites-le intentionnellement, dans un but précis en

tête, et soyez prêt à être distrait.

• Préparez vos questions avant l’entretien. Vous pouvez mener un entretien

assez facilement si vous disposez d’un ensemble de questions

préparées. (Proposer des questions spontanées est rarement une bonne

idée, même si vous êtes un intervieweur expérimenté et que vous êtes

hautement qualifié pour produire des questions ponctuelles.) Avoir une liste

de questions préparée vous permet de fournir une orientation et une

orientation. pour l'entretien, et il offre aux participants une continuité de

pensée. Votre entretien se déroulera plus facilement et sera plus productif

lorsque vos questions passeront facilement d'un sujet à l'autre.

 Lorsque vous préparez votre liste de questions d'entretien, assurez-vous

d'utiliser des questions ouvertes. Par exemple, « Avez-vous estimé que notre

service était (a) médiocre, (b) moyen ou (c) bon ? » est une question

fermée. Une question fermée n'est pas particulièrement utile car elle fournit

son propre ensemble de réponses et ne permet pas à la personne interrogée

de donner une opinion objective ou une réponse élaborée. D’un autre côté,

une question ouverte du type « Que pensez-vous de notre service ? est bien

plus utile car il permet à la personne interrogée de répondre à la question

de différentes manières. Il y a des moments oùvous devrez peut-être utiliser

des questions fermées, mais il est préférable de les utiliser

intentionnellement, avec parcimonie et dans un but précis en tête.

• Si vous n'êtes pas très doué pour prendre des notes, confiez cette tâche à

un transcripteur fiable pour chaque entretien ou informez le groupe à

l'avance que vous allez enregistrer l'entretien à des fins de référence. Vous
menez des entretiens pour recueillir des informations spécifiques sur

l'organisation. Il est donc important que vous établissiez un compte rendu

raisonnablement détaillé de chaque entretien. Si vous avez du mal à mener

un entretien et à prendre des notes en même temps, vous devez demander

à l'un des participants de devenir votre assistant pour prendre des notes à

votre place. (C'est un bon moyen d'encourager la participation de personnes

normalement calmes ou réservées.) Choisissez votre assistant avec soin, car

les notes pourraient en pâtir si cette personne était distraite par les

débats. Une autre option dont vous disposez consiste à enregistrer les

débats de l’entretien. Cela pourrait s'avérer être une meilleure façon de

gérer vos notes, car l'enregistreur capturera l'entretien avec plus de

précision et vous serez en mesure de déterminer exactement qui vous a

fourni une information donnée. Assurez-vous d'informer tous les participants

avant l'entretien si vous décidez de l'enregistrer à des fins de référence. Des

problèmes de confidentialité peuvent être en jeu, et vous ne voulez pas

vous causer, ni causer à quelqu'un d'autre, des ennuis.

• Accordez à chacun votre attention égale et sans partage. C’est un point

crucial à retenir : vous devez prêter toute votre attention à la personne qui

parle et le faire sincèrement. Si vous donnez aux participants l'impression

que vous vous ennuyez, que vous n'êtes pas intéressé ou que vous êtes

préoccupé, ils réduiront immédiatement leur niveau de participation à

l'entretien. D'un autre côté, ils participeront probablement avec beaucoup

d'enthousiasme s'ils voient que vous êtes intéressé par ce qu'ils disent et

que vous bénéficiez de toute votre attention.

Je suis sûr que vous savez qu'il y aura des moments où un participant

répondra à vos questions par des réponses vagues ou incomplètes.Ils

peuvent réagir de cette façon pour plusieurs raisons. Il se peut qu'ils ne

sachent pas vraiment comment exprimer les idées qu'ils souhaitent

véhiculer ou qu'ils ne soient pas libres de divulguer certaines informations. Il

se peut également qu'ils ne soient tout simplement pas à l'aise pour parler

d'eux-mêmes et de ce qu'ils font ou qu'ils se méfient de vous pour une

raison quelconque. Il vous suffira d'être patient et de les mettre à l'aise pour

qu'ils vous fournissent les informations dont vous avez besoin. Par exemple,

vous pouvez essayer d'exprimer votre meilleure approximation de ce qui a

été dit jusqu'à présent et demander si c'est ce qu'ils voulaient dire.

• Gardez le rythme de l’entretien en mouvement. Vous avez probablement

assisté à des réunions au cours desquelles un point particulier a été discuté

ou beaucoup de temps a été passé à essayer d'extraire des informations

d'un participant réticent. Vous pouvez éviter que cela ne se produise lors de

vos entretiens en fixant des limites personnelles quant au temps que vous

accorderez pour répondre à une question et au temps que vous consacrerez

à un sujet spécifique. N'informez pas les participants de cette

limite ; indiquez plutôt que vous déposerez le point pour l'instant afin que la

réunion puisse se poursuivre. Assurez-vous de contacter le propriétaire de la

base de données peu de temps après la réunion afin de pouvoir parvenir à

une conclusion finale et à une résolution du problème.

• Gardez toujours le contrôle de l’entretien. Il s’agit de la ligne directrice la

plus importante pour chaque entretien que vous menez. Inévitablement,

quelque chose ne va pas au moment où vous perdez le contrôle de

l’entretien. Par exemple, supposons que vous vous trouviez dans une

situation où l'un des participants commence à changer l'orientation de

l'entretien en discutant de questions qui ont peu ou pas de rapport avec les

sujets de votre ordre du jour. Vous perdrez certainement le contrôle de

l'entretien à moins que vous ne fassiez quelque chose pour réorienter la

discussion. Reprendre le contrôle de l'entretien vous sera facile dans

certains cas, mais dans d'autres il vous suffira de déclarer votre partie de

l'entretien « terminée » et de laisser les participants poursuivre leur

discussion.

Vous rencontrerez également occasionnellement un participant qui voudra

peut-être dominer l'entretien et répondre à chacune de vos questions. Lorsque

cela se produit, informez-les diplomatiquement et poliment qu'il est de votre

devoir (et de votre devoir) d'obtenir les commentaires de tous les participants

afin que vous puissiez procéder à une évaluation complète des besoins globaux

d'information de l'organisation. Si cela ne résout pas le problème, vous avez

toujours la possibilité de ne pas inclure ce participant dans les discussions

futures. Vous pouvez éviter de telles situations tant que vous gardez le contrôle

de l’entretien. Les entretiens font partie intégrante du processus de conception

et j'en donne des exemples tout au long des chapitres suivants. Vous trouverez

des exemples de dialogues illustrant des scénarios d'entretien typiques et des

exemples de questions que vous pourriez utiliser lors d'un entretien

donné. (Les exemples de questions se rapportent toujours au type d'entretien

que vous menez actuellement.)

Note
Le but d'un exemple d'entretien est d'illustrer les techniques que vous utilisez

pour mener un type spécifique d'entretien, et j'ai gardé le dialogue

relativement simple pour cette raison. Utilisez le dialogue comme moyen de

trouver de bonnes idées pour les types de conversations que vous menez lors

de l'entretien.

Un dernier point : gardez à l’esprit que les lignes directrices que j’ai présentées

dans cette section ne sont que des recommandations. Je soupçonne que vous

ne pourrez pas appliquer toutes ces directives à chaque entretien que vous

mènerez ni même les appliquer dans la mesure où je l'ai décrit. J'attendrais

cependant de vous que vous les appliquiez pleinement dans une situation

idéale. Oui, je sais, on ne rencontre pas toujours des situations idéales. Moi non

plus. Mais vous pouvez toujours vous fixer comme objectif de respecter autant

de ces directives que possible. En fin de compte, la personne qui a le plus à

gagner, c’est vous.

Définir l'énoncé de mission

Dans le chapitre précédent, vous avez appris que l' énoncé de mission déclare

l'objectif spécifique de la base de données en termes généraux et que vous le

définissez au début du processus de conception de la base de données. De

plus, cela vous permet de concentrer vos efforts de conception et vous évite de

vous laisser détourner et de rendre la structure de la base de données

inutilement volumineuse ou complexe.

L'énoncé de mission bien rédigé

Un bon énoncé de mission est succinct et précis. Les déclarations verbeuses

ont tendance à être confuses, ambiguës ou vagues ; ils font plus pour obscurcir

l’objectif de la base de données que pour le clarifier. Voici un exemple d’énoncé

de mission typique :

Le but de la base de données New Starz Talent Agency est de conserver les

données que nous générons et de fournir des informations qui soutiennent les

services d'engagement que nous fournissons à nos clients et les services de

gestion que nous fournissons à nos artistes.

Cet énoncé de mission est bien défini et épuré de déclarations ou de détails

inutiles. C’est une déclaration très générale, comme il se doit. Considérez un

énoncé de mission comme la flamme d’une bougie située au bout d’un tunnel

sombre. La lumière produite par la flamme vous guide jusqu’au bout du tunnel,

à condition de vous concentrer dessus. De la même manière, l'énoncé de

mission vous guide jusqu'à la fin du processus de conception de la base de

données. Guidé par votre énoncé de mission, vous pouvez vous concentrer sur

la conception d’une structure de base de données qui prendra en charge

l’objectif déclaré de la base de données.

Un énoncé de mission bien rédigé ne contient pas d'expressions ou de phrases

décrivant explicitement des tâches spécifiques. Si votre énoncé de mission

contient ce type d’expressions ou de phrases, supprimez-les et réécrivez

l’énoncé. Assurez-vous cependant de garder les phrases supprimées à portée

de main,car vous pourrez peut-être les utiliser pour formuler des objectifs de

mission. (Vous découvrirez les objectifs de la mission dans la section suivante.)

Voici un exemple d'énoncé de mission mal formulé :

L'objectif de la base de données de l'examinateur d'audition du comté de

Whatcom est de garder une trace des demandes d'utilisation des terres, de

conserver des données sur les candidats, de conserver un enregistrement de

toutes les audiences, de conserver un enregistrement de toutes les décisions,

de conserver un enregistrement de tous les appels, de conserver des données

sur les employés du département. et conserver les données pour un usage

bureautique général.

Il devrait être immédiatement évident que certaines choses ne vont pas dans

cet énoncé de mission.

• C'est un peu verbeux. N'oubliez pas que l'énoncé de mission idéal doit être

succinct et précis.

• L’objectif spécifique de la base de données n’est pas clair. Cet énoncé de

mission est rédigé de telle manière qu'il est difficile de déterminer l'objectif

spécifique de la base de données.

• Il décrit plusieurs tâches spécifiques. Deux problèmes se posent lorsqu’un

énoncé de mission est rédigé de cette manière. Premièrement, la

description des tâches ne définit en rien l’objectif spécifique de la base de

données. Deuxièmement, la déclaration semble en quelque sorte

incomplète. Cela soulève la question : « Y a-t-il des tâches que nous avons

oublié d'inclure dans l'énoncé de mission ? »

Vous pouvez corriger cet énoncé de mission en supprimant les références à des

tâches spécifiques (assurez-vous de les enregistrer pour l'étape suivante) et en

réécrivant l'énoncé. Voici un exemple d’une des façons possibles de réécrire cet

énoncé de mission :
L'objectif de la base de données de l'examinateur auditif du comté de

Whatcom est de conserver les données que le bureau de l'examinateur utilise

pour prendre des décisions sur les demandes d'utilisation des terres soumises

par les citoyens du comté de Whatcom.

Remarquez à quel point le but de la base de données est devenu beaucoup

plus clair dans cette version. Notez également que la déclaration est plus

succincte et ne précise pasdonner l'impression d'être incomplet. Vous aurez

toujours une orientation claire pendant le processus de conception de la base

de données lorsque vous formulerez vos énoncés de mission de cette manière.

Rédiger un énoncé de mission

Le processus de création d'un énoncé de mission implique de mener un

entretien avec le propriétaire ou le responsable de l'organisation, de se

renseigner sur l'organisation et de déterminer l'objectif de la nouvelle base de

données.

Vous menez l'entretien pour cette étape avec le propriétaire de l'organisation

ou, s'il le demande, le membre du personnel approprié. L’un ou l’autre pourra

vous aider à définir l’énoncé car chacun a une compréhension globale de

l’organisation et une compréhension générale de la raison pour laquelle la base

de données est nécessaire en premier lieu. En plus de vous aider à définir

l'énoncé de mission, cet entretien vous fournira également de nombreuses

informations sur l'organisation elle-même. Ces informations sont précieuses car

vous pourrez les utiliser plus tard dans le processus de conception.

Encouragez les participants aux entretiens à discuter d'autant de facettes de

l'organisation que possible, même si la discussion porte sur des questions qui

ne sont pas directement pertinentes pour la base de données. L'idée ici est que

vous compreniez ce que fait l'organisation et comment elle fonctionne ; Plus

vous comprendrez une organisation, mieux vous serez préparé à concevoir une

base de données qui répondra à ses besoins. Le besoin général de

l’organisation en matière de base de données vous deviendra clair une fois que

vous aurez une meilleure compréhension de l’organisation elle-même. Vous

pouvez ensuite traduire ce besoin en un énoncé de mission.

Assurez-vous de poser des questions ouvertes pendant l’entretien. Dans

certains cas, une bonne question peut inciter le participant à énoncer le but de

la base de données sans trop d’effort. Par exemple, disons que vous posez la

question suivante :

« Comment décririez-vous l'objectif de votre organisation à un nouveau

client ? »

Il s'agit d'une bonne question ouverte car elle se concentre sur le problème

tout en donnant au participant la liberté de répondre avec ce qu'il considère

comme une réponse complète. De plus, ce type de question générera

généralement une réponse que vous pourrez traduire directement en énoncé

de mission.

Supposons maintenant que vous ayez reçu la réponse suivante :

« Nous fournissons des services de divertissement à notre clientèle pour toutes

les occasions. Nous nous occupons de tous les détails de la mission afin qu’elle

soit aussi sereine que possible pour le client.

Vous pouvez facilement réécrire ce type de réponse et en faire un énoncé de

mission. Lorsqu'une réponse comme celle-ci se compose de deux phrases ou

expressions ou plus, l'une des phrases ou expressions indique généralement

l'objectif de la base de données. Par exemple, vous pouvez utiliser la première

phrase de la réponse précédente pour construire l'énoncé de mission. Voici

l’une des différentes façons dont vous pouvez réécrire la réponse :

Le but de la base de données All-Star Talent est de conserver les données que

nous utilisons pour soutenir les services de divertissement que nous

fournissons à notre clientèle.

Le point le plus important à retenir est que l’énoncé de mission doit avoir un

sens pour vous (le développeur de la base de données) et pour ceux pour qui

vous concevez la base de données. Différents groupes de personnes ont

différentes manières de formuler les déclarations, et la formulation spécifique

de la déclaration peut dépendre grandement de la terminologie spécifique au

secteur. Votre énoncé de mission est complet lorsque vous disposez d'une

phrase qui décrit l'objectif spécifique de la base de données et qui est comprise

et acceptée par toutes les personnes concernées.

Voici quelques exemples de questions que vous pouvez utiliser pour parvenir à

votre énoncé de mission :

Comment décririez-vous l’objectif de votre organisation à un nouveau client ?

Selon vous, quel est le but de votre organisation ?

Quelle est la fonction principale de votre organisation ?

Comment décririez-vous ce que fait votre organisation ?

Comment définiriez-vous la raison la plus importante de l’existence de votre

organisation ?

Quel est l’objectif principal de votre organisation ?

Vous avez peut-être remarqué que certaines de ces questions semblent être les

mêmes, réécrites de manière différente. Gardez à l'esprit que l'observation

concernant la formulation des énoncés de mission s'applique également aux

questions d'entretien que vous utiliserez tout au long du processus de

conception de la base de données. Vous pouvez poser la même question à

plusieurs personnes et recevoir des réponses différentes car chaque personne

peut interpréter le sens de la question un peu différemment. Dans certains cas,

vous pouvez simplement avoir un long regard du type « Je n'ai pas encore bu

mon premier expresso ». Expérimentez différents types de formulation et

déterminez celui qui vous convient le mieux. Votre méthode de construction et

de pose de questions peut être différente de celle de quelqu'un d'autre, mais

cela n'a pas d'importance tant que vous avez une méthode qui vous convient.

EXEMPLE : DÉFINIR UN ÉNONCÉ DE MISSION

Voyons comment vous définiriez un énoncé de mission pour une petite

entreprise connue sous le nom de « Mike's « Bikes ». C'est un petit magasin de

vélos situé dans une zone commerçante de banlieue parmi d'autres petites

entreprises. Avant de pouvoir définir l'énoncé de mission, vous devez mener un

entretien avec le propriétaire, Mike, pour recueillir des informations sur son

entreprise. L’entretien peut ressembler à ceci :

TOI :« Pouvez-vous me dire pourquoi vous pensez avoir besoin d'une base de

données ? »
MIKE :« Je pense que nous avons besoin d’une base de données uniquement

pour suivre tout notre inventaire. J'aimerais également garder une trace de

toutes nos ventes.

TOI :« Je suis sûr que la base de données résoudra ces problèmes. Maintenant,

quelle est, selon vous, la fonction la plus importante de votre entreprise ? »

MIKE :« Fournir à nos clients une large gamme de produits et de services liés au

vélo. Nous avons beaucoup de bons clients. Et les réguliers aussi ! Ils sont

notre plus grand atout.

(L'entretien continue jusqu'à ce que vous ayez fini de poser toutes les

questions de votre liste.)

Après l'entretien, examinez les informations que vous avez recueillies et

définissez l'énoncé de mission. Vous pouvez constater quelques points lors du

dialogue précédent avec Mike, comme le fait qu'il devra être capable de suivre

les produits, les clients et les ventes des clients. Mais le point le plus précieux

est fourni par sa réponse à la deuxième question. Vous pouvez utiliser la

première phrase de cette réponse pour formuler l'énoncé de mission. En tenant

compte de certains des autres points que vous avez identifiés lors de

l'entretien, vous pouvez réécrire la réponse de Mike pour créer l'énoncé de

mission suivant :

Le but de la base de données Mike's Bikes est de conserver les données dont

nous avons besoin pour soutenir notre activité de vente au détail et nos

opérations de service client.

Lorsque vous pensez avoir un bon énoncé de mission, examinez-le avec Mike et

assurez-vous qu'il comprend et accepte l'objectif déclaré de la base de

données. Lorsque vous et Mike êtes satisfaits de l'énoncé de mission, vous

pouvez passer à l'étape suivante, qui consiste à définir les objectifs de la

mission.

Définir les objectifs de la mission

Pour développer l'aperçu du chapitre précédent, les objectifs de mission sont

des énoncés qui représentent les tâches générales prises en charge par les

données conservées dans la base de données. Chaque objectif de mission

représente une tâche unique . Ces objectifs de mission fournissent des

informations que vous pourrezutiliser tout au long du processus de conception

de la base de données. Par exemple, les objectifs de mission vous aident à

définir des structures de table, des spécifications de champ, des

caractéristiques de relation et des vues. Ils vous aident également à établir

l’intégrité des données et à définir des règles métier. Enfin, les objectifs de

mission guident vos efforts de développement et garantissent que la structure

finale de votre base de données prend en charge l'énoncé de mission.

Objectifs de mission bien rédigés

Un objectif de mission bien rédigé est une phrase déclarative qui définit

clairement une tâche générale et est exempte de détails inutiles. Il est exprimé

en termes généraux, succincts, précis et sans ambiguïté. Voici quelques

exemples d’objectifs de mission typiques :

Conserver les informations complètes sur l’adresse du patient.

Gardez une trace de toutes les ventes des clients.

Assurez-vous qu'un représentant de compte n'est pas responsable de plus de

20 comptes à la fois.

Gardez une trace de l’entretien du véhicule.

Produire des annuaires téléphoniques des employés.

Ces objectifs de mission sont bien définis et faciles à comprendre. Chaque

objectif de mission représente une seule tâche générale et définit clairement la

tâche sans détails inutiles. Par exemple, le dernier objectif de mission de la

liste indique que les annuaires des employés doivent être produits, mais il

n'indique pas comment ils doivent être produits. Il n'est pas nécessaire

d'indiquer comment les annuaires des employés seront produits, car cette

question fait partie du processus de développement de l'application. N'oubliez

pas que le but d'un objectif de mission est d'aider à définir diverses structures

au sein de la base de données et d'aider à guider l'orientation globale du

développement de la base de données.

Si un objectif de mission représente plus d’une tâche générale, vous devez le

décomposer en deux ou plusieurs objectifs de mission. Voici un exemple

d’objectif de mission mal rédigé :

Nous devons garder une trace des artistes que nous représentons et du type de

divertissement qu'ils proposent, ainsi que des engagements que nous

réservons pour eux.

Il y a deux problèmes avec cet objectif de mission.

1. Il définit plus qu’une simple tâche générale. Il est clair que deux tâches sont

représentées dans cette déclaration : garder la trace des artistes et garder

la trace des engagements.

2. Il contient des détails inutiles. Il n'est pas nécessaire de faire référence au «

type de divertissement » de l'artiste dans cet objectif de

mission. L'expression type de divertissement fait référence à une

caractéristique distincte d'un artiste ou représente une nouvelle tâche qui

devrait être déclarée comme objectif de mission. S'il fait référence à une

caractéristique distincte d'un artiste, il doit être supprimé de la

déclaration ; sinon, il devrait servir de base à un nouvel objectif de mission.

Vous pouvez corriger cet objectif de mission en supprimant les détails inutiles

et en le réécrivant en deux objectifs de mission. (Conservez les détails que

vous supprimez sur une liste séparée ; ils peuvent être utiles plus tard dans le

processus de conception.) Voici un exemple de révision possible :

Conservez des informations complètes sur les artistes.

Gardez une trace de tous les engagements que nous réservons.

Notez que chaque objectif de mission définit désormais clairement une seule

tâche générale et est également facile à comprendre. De tels objectifs de

mission sont faciles à utiliser lors de la conception de la base de données.

Composition des objectifs de la mission

La définition des objectifs de mission est un processus qui implique de mener

des entretiens avec les utilisateurs et la direction, puis de rédiger des objectifs

de mission appropriés sur la base des informations recueillies lors des

entretiens.
Le but de l'entretien est de déterminer quels types de tâches générales doivent

être prises en charge par les données de la base de données. Vous y parvenez

en posant des questions ouvertes aux participants et en leur permettant de

développer leurs réponses si nécessaire. Les entretiens sur l'énoncé de mission

et les objectifs de mission sont les entretiens les plus faciles que vous menerez

pendant le processus de conception, car tout le monde est généralement

enthousiaste à l'idée de participer. (D'après mon expérience, du moins.) Il est

assez facile d'amener les gens à discuter de ce qu'ils font au quotidien et à

donner leur point de vue sur le fonctionnement de l'organisation. C'est

également l'un des rares entretiens que vous menerez à la fois avec les

utilisateurs et la direction ; il devrait y avoir beaucoup de points communs

entre les deux groupes en raison de la nature générale de l’entretien.

Un point très important à retenir est que les entretiens que vous menez ici

impliquent des discussions très générales. Les discussions sont plus

conceptuelles qu’analytiques ; votre intention ici n'est pas d'analyser la base

de données ou l'application de base de données actuelle, mais d'avoir une idée

globale des tâches générales que la base de données doit prendre en

charge. Gardez à l’esprit que l’un des objectifs de la mission est d’aider à

guider le développement de la structure de la base de données.

Pendant que vous menez l’entretien, assurez-vous, encore une fois, de poser

des questions ouvertes. N'oubliez pas que les questions ouvertes sont

susceptibles de susciter de meilleures réponses de la part de vos

participants. Posez aux participants des questions concernant leur travail

quotidien, le fonctionnement de l'organisation et le type de problèmes qui,

selon eux, doivent être résolus par la base de données. Encouragez-les à

discuter d’autant de facettes de leur travail et de l’organisation que

possible. Pendant qu’ils répondent, essayez d’enregistrer chaque réponse sous

forme de phrase déclarative. Vous constaterez qu'il est beaucoup plus facile

detransformez une phrase en objectif de mission si vous pouvez le faire. Voici

quelques exemples des types de questions que vous pourriez poser lors de

l’entretien :

Quel type de travail effectuez-vous au quotidien ?

Comment définiriez-vous votre description de poste ?

Avec quel type de données travaillez-vous ?

Quels types de rapports générez-vous ?

Quels types de choses suivez-vous ?

Quels types de services votre organisation fournit-elle ?

Comment décririez-vous le type de travail que vous effectuez ?

Toutes ces questions sont susceptibles de susciter une bonne et longue

réponse de la part du participant. L’un des avantages de ces questions est

qu’elles vous offrent la possibilité de poser des questions complémentaires. Par

exemple, supposons que vous ayez reçu la réponse suivante à la dernière

question de la liste :
« Tout d'abord, j'essaie de déterminer le problème général du véhicule. Ensuite,

je remplis un bon de travail et note mon évaluation du problème. Enfin, j'envoie

le véhicule à la prochaine équipe de service disponible.

Vous remarquerez immédiatement que la réponse est longue, ce qui est très

bien. Vous devez également noter que vous pouvez facilement poser une

question complémentaire, telle que la suivante :

« Y a-t-il un type d'information client incorporé dans la procédure que vous

venez de décrire ? »

Même si la réponse est « Non », la question reste suffisamment ouverte pour

que le participant puisse développer davantage sa réponse initiale. Ce type de

question complémentaire pourrait également perturber sa mémoire et l'amener

à relayer d'autres informations, pouvant être liées au sujet de la réponse

initiale.

Voici un ensemble d’objectifs de mission que vous pourriez déduire de la

réponse originale du participant :

Maintenir les informations sur les véhicules des clients.

Gardez une trace des bons de travail.

Maintenir les informations sur nos équipes de service.

Maintenir les informations sur nos mécaniciens.

Maintenir les informations sur nos clients.

Trois de ces objectifs découlent directement de la réponse. Ils sont faciles à

déterminer car leurs sujets sont explicitement indiqués dans la réponse elle-

même. Les deux derniers objectifs de la mission découlent

d' hypothèses basées sur la réponse. Il s'agit d'une technique (que vous pouvez

considérer comme « lire entre les lignes ») que les concepteurs de bases de

données expérimentés utilisent assez souvent, et c'est une technique que vous

devez utiliser lorsque vous définissez les objectifs de la mission. La technique

repose sur votre capacité à déterminer quelles informations une réponse

transmet implicitement, ainsi que ce qu'elle transmet explicitement. Alors

faites attention. Écoutez les implications. Sans de bonnes hypothèses, votre

ensemble global d’objectifs de mission pourrait être incomplet.

Examinez la réponse suivante et déterminez si des informations implicites sont

cachées dans la réponse elle-même :

« Je réserve des animations pour notre clientèle, composée de clients

commerciaux et non commerciaux. Nos clients non commerciaux sont

généralement des particuliers ou de petits groupes qui réservent des mariages,

des anniversaires, etc. Nos clients commerciaux, quant à eux, sont constitués

d'entreprises telles que des boîtes de nuit et des entreprises. Les boîtes de nuit

réservent des divertissements sur des créneaux de six semaines ; les

entreprises réservent des choses telles que des soirées d'entreprise, des

déploiements de produits et divers types de fonctions promotionnelles.

Outre les informations explicites véhiculées par cette réponse, il existe au

moins deux informations implicites que vous pouvez découvrir danscette

réponse. La première information implicite concerne la nécessité de conserver

des informations sur les artistes réservés pour les engagements. Un agent doit

connaître des éléments tels que le nom de l'artiste, son numéro de téléphone,

son adresse postale, sa disponibilité et s'il se rendra à l'extérieur de la ville. La

deuxième information implicite concerne la nécessité de conserver des

informations sur les engagements eux-mêmes. Un agent doit connaître tous les

détails concernant la mission pour garantir le bon déroulement de la mission.

Maintenant que vous savez à quel point il est important de rechercher des

informations implicites, gardez-les à l'esprit lorsque vous définissez les

objectifs de votre mission.

Voici l'essentiel concernant les objectifs de mission : assurez-vous que les

objectifs de votre mission sont à la fois correctement définis et bien définis,

que chaque objectif a du sens pour vous et pour ceux pour qui vous concevez

la base de données, et que vous recherchez toute information implicite cachée

dans la réponse de chaque participant.

EXEMPLE : DÉFINIR LES OBJECTIFS DE LA MISSION

Travaillons à nouveau avec Mike et interviewons-le afin qu'il puisse vous aider à

définir les objectifs de mission de sa base de données. Voici une transcription

partielle de l'entretien avec Mike. Encore une fois, c'est vous qui menez

l'interview.

TOI :« Pouvez-vous me donner une idée des éléments que vous aimeriez suivre

dans la base de données ? »

MIKE :« Oh, bien sûr, c'est assez facile. Je veux garder une trace de notre

inventaire, de nos clients et de nos ventes.

TOI :« Pensez-vous à autre chose qui soit lié à ces sujets ?

MIKE _"Eh bien, je suppose que si nous voulons suivre notre inventaire, nous

devrions savoir qui sont nos fournisseurs."

TOI :« Qu'en est-il des commerciaux impliqués dans chaque vente ? »

MIKE :« Oh oui, nous devrions absolument conserver des informations sur nos

employés. Au moins, c'est une bonne idée de le faire du point de vue des

ressources humaines. Du moins, c'est ce que me dit ma femme !

(L'entretien continue jusqu'à ce que vous ayez fini de poser toutes les

questions de sa liste.)

Une fois les entretiens terminés, examinez toutes les informations que vous

avez recueillies et définissez les objectifs de mission appropriés. Assurez-vous

de garder les résultats à l’esprit lorsque vous les définissez. Voici quelques

objectifs de mission possibles pour la base de données Mike's Bikes.

Maintenir des informations complètes sur l'inventaire.

Maintenir des informations client complètes.

Suivez toutes les ventes des clients.

Maintenir des informations complètes sur les fournisseurs.

Conserver des informations complètes sur les employés.

Après avoir dressé une liste d'objectifs de mission, examinez-les avec Mike et

son équipe. Lorsqu'ils sont convaincus qu'ils comprennent les objectifs de la

mission et que la liste est relativement complète, enregistrez-la dans un

document de votre programme d'application préféré et enregistrez-la pour une

utilisation ultérieure.

Résumé

Ce chapitre s'est ouvert sur une discussion du processus d'entretien. Vous avez

appris pourquoi les entretiens constituent une partie importante du processus

de conception de bases de données et pourquoi il est important d'apprendre à

mener correctement un entretien. Vous connaissez désormais la différence

entre une question ouverte et une question fermée , ainsi que quand utiliser

chaque type de question. Nous avons terminé cette discussion en examinant

un ensemble de directives d'entretien,et vous avez appris que vous devez les

utiliser pour vous aider à garantir que les entretiens soient productifs et

réussis.

L’ énoncé de mission était notre prochain sujet de discussion. Nous avons

développé les informations du chapitre 4 , « Aperçu conceptuel », en

examinant comment l'énoncé de mission énonce l'objectif spécifique de la base

de données. Vous savez maintenant que le processus implique de mener des

entretiens et de se renseigner sur l'organisation, puis de formuler l'énoncé de

mission à partir des informations que vous avez recueillies au cours de ces

étapes. Nous avons défini les caractéristiques d'un bon énoncé de mission et

vous avez appris qu'un énoncé de mission bien défini établit une orientation

claire pour vos efforts de conception.

Ensuite, nous avons discuté des objectifs de la mission et nous avons encore

une fois développé l’aperçu du chapitre 4 . Comme vous le savez maintenant,

les objectifs de mission représentent les tâches effectuées par rapport aux

données de la base de données, et vous les définissez après l'énoncé de

mission. Nous avons ensuite exploré comment définir un objectif de

mission. Ici, vous avez appris que vous menez des entretiens avec les

utilisateurs et la direction et que les informations que vous recueillez à partir

de ces entretiens constituent la base de chaque objectif de mission. Nous

avons également discuté des caractéristiques d'un objectif de mission bien

rédigé et vous avez appris qu'un objectif de mission clairement défini vous

aidera à définir diverses structures au sein de la base de données.

Questions de révision

1. Pourquoi les entretiens sont-ils importants ?

2. Quel problème peut survenir lorsque vous menez un entretien avec un grand

nombre de personnes ?

3. Quelle est la principale raison pour laquelle des entretiens séparés sont

menés avec les utilisateurs et la direction ?

4. Vrai ou faux : vous utiliserez généralement des questions fermées lors de

vos entretiens.

5. Quel genre de réponses devriez-vous essayer de susciter de la part des

participants à l’entretien ?

6. Quelle est la ligne directrice la plus importante pour chaque entretien que

vous menez ?

7. Qu'est-ce qu'un énoncé de mission ?

8. Énoncez deux caractéristiques d’un énoncé de mission bien rédigé.

9. Vrai ou faux : Vous n'avez pas besoin de vous renseigner sur l'organisation

pour rédiger un énoncé de mission.

10. Quand votre énoncé de mission est-il terminé ?

11. Qu'est-ce qu'un objectif de mission ?

12. Énoncez deux caractéristiques d’un objectif de mission bien rédigé.

13. Vrai ou faux : vous devez interroger les utilisateurs et la direction pour vous

aider à définir les objectifs de la mission.

14. Quel est le lien entre le travail quotidien du personnel et les objectifs de la

mission ?

15. Vrai ou faux : Un objectif de mission peut décrire plusieurs tâches.

16. Énoncez deux façons dont un objectif de mission peut être dérivé d’une

réponse.

17. Quand un objectif de mission est-il atteint ?

t
adqP
r
bouae
lserc
euah
e
m
dèr
etc
srh
e
m
s
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
5. Démarrage du processus
6. Analyse de la base de données actuelle
7. Établir des structures de table
8h 33min restantes

Analyse de la base de données actuelle

Pour voir ce qui est devant son nez, il faut une lutte constante.

—G EORGE O RWELL

DEVANT VOTRE NEZ _ __ __

Sujets abordés dans ce chapitre

Apprendre à connaître la base de données actuelle

Réalisation de l'analyse

Examiner la manière dont les données sont collectées

Examiner la façon dont les informations sont présentées

Mener des entretiens

Interviewer les utilisateurs

Gestion des entretiens

Compilation d'une liste complète de champs

Exemple : Analyse de la base de données actuelle

Résumé

Questions de révision

Apprendre à connaître la base de données actuelle

Pour déterminer où vous devriez aller, vous devez d’abord comprendre où vous
vous trouvez .

Cette maxime définit toute la philosophie derrière cette phase du processus de

conception de base de données. Vous devez consacrer du temps à bien

comprendre la base de données de votre organisation afin de pouvoir

• Déterminer si la base de données prend en charge les besoins actuels en

informations de l'organisation
• Découvrez les déficiences structurelles existantes

• Déterminer comment la base de données doit évoluer afin qu'elle réponde

aux futurs besoins d'information de l'organisation.

Vous pouvez utiliser la base de données existante comme ressource pour

développer une nouvelle base de données. Cependant, vous devez

soigneusement évaluer quels aspects de la base de données actuelle restent

utiles et quels aspects doivent être abandonnés. Vous pouvez porter ces

jugements en répondant aux questions suivantes :

Quels types de données l’organisation utilise-t-elle ?

Comment l’organisation utilise-t-elle ces données ?

Comment l’organisation gère-t-elle et conserve-t-elle ces données ?

Les réponses à ces questions vous fournissent des informations vitales que

vous pouvez utiliser pour concevoir une base de données la mieux adaptée aux

besoins de votre organisation.

Vous pouvez mieux répondre à ces questions en analysant la base de données

existante de votre organisation. Il est très probable que l'organisation utilise un

certain type de base de données, et elle peut probablement être associée à

l'une des catégories suivantes.

• Bases de données papier . Également appelés systèmes de fichiers , ils se

composent généralement de divers formulaires et de documents manuscrits

ou imprimés stockés dans des dossiers ou reliés dans des cahiers. Les

dossiers et cahiers sont identifiés par un système de codage (par exemple,

des numéros uniques ou des onglets colorés) et stockés dans des

classeurs. Ces armoires sont susceptibles d'être identifiées par un système

de codageégalement, en fonction de la taille de la base de données. (Vous

seriez surpris du nombre d'entreprises qui disposent encore d'une forme ou

d'une autre de système papier.)

• Les bases de données existantes existent et sont utilisées depuis plusieurs

années et se composent de divers types de structures de données et

d'interfaces utilisateur qui résident toutes sur des ordinateurs centraux, des

serveurs réseau, des ordinateurs personnels ou, plus récemment, sur le

cloud. La capacité, la fonctionnalité et l'efficacité des structures et des

écrans dépendent largement des compétences et des connaissances des

développeurs, des outils de développement d'applications et du logiciel de

gestion de bases de données utilisé pour les créer.

• Les bases de connaissances humaines (vaguement définies) sont basées sur

la mémoire d'un ou plusieurs employés au sein d'une organisation. Ces

personnes possèdent une quantité spécifique de connaissances concernant

un aspect donné de l'organisation (par exemple, des informations sur les

clients ou des détails sur les produits) et elles jouent un rôle crucial dans la

conduite des activités de l'organisation.

Les objectifs de votre analyse sont de déterminer les types de données que

l'organisation utilise, la manière dont l'organisation gère et conserve ces

données, et la manière dont l'organisation visualise et utilise les données. Vous

pouvez réduire le temps nécessaire à la définition des structures préliminaires

de champs et de tables pour la nouvelle base de données si vous effectuez

cette enquête correctement.

Au cours de l'analyse, vous examinez les différentes manières dont

l'organisation collecte et présente ses données, et vous menez une série

d'entretiens avec les utilisateurs et la direction. Vous utilisez ensuite les

informations que vous avez collectées pour définir une liste de champs

préliminaire et pour déterminer les tables qui doivent être incluses dans la

structure de base de données initiale. Si votre analyse révèle que la base de

données actuelle est mal conçue, vous pouvez prendre des précautions pour

vous assurer de ne pas commettre les mêmes erreurs dans la nouvelle base de

données. Malgré les défauts de la base de données actuelle, elle peut toujours

vous aider à identifier un certain nombre de champs et de tables que vous

devriez inclure dans la nouvelle base de données.

Il y a une règle que vous devez avant tout garder à l’esprit lorsque vous

analysez la base de données actuelle :

N'adoptez pas la structure de base de données actuelle comme base pour la

nouvelle structure de base de données.

Suivre cette règle vous aidera à éviter les erreurs inutiles et à maximiser vos

efforts de conception.
De temps en temps, il y a un moment au cours de l'analyse où un développeur

de base de données novice (et parfois expérimenté) s'arrêtera et pensera : «

Cette base de données n'a pas l'air trop mauvaise. Terminons ici l'analyse et

utilisons cette base de données comme base pour la nouvelle. C'est une idée

particulièrement mauvaise car tous les problèmes cachés dans la structure

actuelle de la base de données seront transférés dans la nouvelle base de

données. Ces types de problèmes incluent des structures de table maladroites,

des relations mal définies et des spécifications de champ incohérentes ; ils

feront invariablement surface plus tard et aux moments les moins

opportuns. Par conséquent, vous devez faire de votre mieux pour éviter cette

situation périlleuse en suivant la règle susmentionnée. N'oubliez pas qu'il est

toujours préférable de définir explicitement une nouvelle structure de base de

données plutôt que de copier une structure existante. Après tout, si l’ancienne

base de données n’avait pas de problèmes, vous n’en créeriez pas une

nouvelle.

Vous analyserez généralement les bases de données papier et les bases de

données existantes au cours de cette partie du processus de conception. De

nombreuses organisations utilisent les deux types de bases de données dans

une certaine mesure et vous effectuez le même processus d'analyse de base

sur chacune d'elles. Il existe bien sûr des différences mineures dans la manière

dont vous analysez une base de données papier et une base de données

existante, mais les différences ont plus à voir avec les bases de données elles-

mêmes qu'avec le processus d'analyse global. Cependant, vous n'avez pas

besoin de vous préoccuper de ces différences, car je les ai intégrées de

manière transparente dans le processus d'analyse présenté dans ce livre.

Bases de données papier

Une base de données sur papier intègre des données qui sont littéralement

collectées, stockées et conservées sur papier, et vous trouverez ces éléments

dans une variété de formes, de tailles et de configurations. Certains des

formats les plus courants incluent des rapports manuscrits ou imprimés et

divers types de formulaires préimprimés. Quiconque a déjà travaillé dans un

bureau pour une entreprise, une organisation ou une agence gouvernementale

connaît très bien ce type de base de données.

Vous constaterez que l’analyse d’une base de données papier peut être une

tâche ardue. L’un de vos problèmes les plus immédiats est de trouver

quelqu’un qui comprend parfaitement le fonctionnement de la base de

données afin que vous puissiez en apprendre davantage sur son utilisation et

son objectif. La base de données elle-même pose plusieurs problèmes,

notamment en termes de manière dont les données sont collectées et

gérées. Ce type de base de données contient généralement des données

incohérentes, des données erronées, des données en double, des données

redondantes, des entrées incomplètes et des données anciennes qui auraient

dû être supprimées de la base de données depuis longtemps. De toute

évidence, la seule raison pour laquelle vous analyserez ce type de base de

données est d’identifier les éléments que vous pourriez incorporer dans la

nouvelle base de données. Par exemple, vous pouvez extraire des éléments de

données individuels de différentes sections d'un formulaire de l'ancienne base

de données et les transformer en champs dans la nouvelle base de données.

Bases de données héritées

Une base de données existante est une base de données qui existe et est

utilisée depuis cinq ans ou plus. Il y a plusieurs raisons pour lesquelles

« héritage » est utilisé dans le nom de ce type de base de

données. Premièrement, cela suggère que la base de données existe depuis

longtemps, peut-être plus longtemps que quiconque ne s’en souvient

clairement. Deuxièmement, le mot héritage peut signifier que la personne qui a

initialement créé la base de données a changé de responsabilités au sein de

l'organisation ou travaille pour quelqu'un d'autre et, par conséquent, la base de

données est devenue son héritage pour

l'organisation.organisation. Troisièmement, le terme implique la possibilité

inquiétante qu’aucun individu ne comprenne complètement la structure de la

base de données ou la manière dont elle est implémentée dans le programme

d’application du SGBDR.

Même si une base de données existante est basée sur le modèle relationnel, il

n'y a aucune garantie particulière que la structure soit

solide. Malheureusement, il existe de nombreux cas dans lesquels les

personnes qui ont créé ces bases de données n'ont pas complètement compris

le concept de base de données relationnelle. (Après avoir lu ce livre, vous

n'appartiendrez plus à ce groupe.) Le résultat est que de nombreuses bases de

données plus anciennes ont des structures inappropriées ou inefficaces.

De nombreuses bases de données existantes sur PC sont également conçues

de manière incorrecte ou inefficace. Un certain nombre d'entre eux ont été

développés et mis en œuvre à l'origine par des personnes qui n'avaient pas

beaucoup d'expérience en conception de bases de données, ou qui étaient des

malchanceux qui se sont vu confier la tâche de créer une base de données

pour l'organisation et qui disposaient de peu de temps pour le faire. (Ils avaient

leur propre travail normal à accomplir.) Cela signifie qu’eux non plus ne

savaient probablement pas comment profiter des avantages offerts par le

modèle relationnel. Deux caractéristiques couramment associées à ces types

de bases de données sont les champs en double et les données

redondantes. Vous apprendrez plus tard que cela peut entraîner de graves

problèmes d’intégrité des données.

L'analyse d'une base de données existante est un peu plus facile que l'analyse

d'une base de données sur papier, car une base de données existante est

généralement plus organisée et structurée qu'une base de données sur papier,

les structures de la base de données sont explicitement définies et il existe

généralement un programme d'application que les utilisateurs utilisent. pour

interagir avec les données de la base de données. (Le programme d'application

vous est précieux pendant le processus d'analyse car il peut révéler de

nombreuses informations sur les structures de données et les tâches

effectuées sur les données de la base de données existante.) Le temps qu'il

vous faudra pour effectuer une analyse appropriée dépendra dans une certaine

mesure sur le type de base de données, le SGBDR utilisé pour implémenter la

base de données existante et le programme d'application.

Le point clé à retenir lorsque vous analysez une base de données papier ou

existante est que vous devez suivre le processus avec patience et méthode

afin de garantir une analyse approfondie et précise.

Réalisation de l'analyse

Le processus d'analyse comporte trois étapes : examiner la manière dont les

données sont collectées, examiner la manière dont les informations sont

présentées et mener des entretiens avec les utilisateurs et la direction.

Vous devrez parler à diverses personnes de l’organisation au cours des deux

premières étapes de ce processus. Assurez-vous que vos conversations portent

uniquement sur les avis disponibles. Vous aurez l’occasion de leur poser
d’autres questions approfondies plus tard. Gardez à l’esprit que ces bilans font

partie intégrante de votre préparation aux entretiens qui suivront. En effet, ces

évaluations vous aident à déterminer les types de questions que vous devrez

poser lors des entretiens ultérieurs.

Examiner la manière dont les données sont collectées

La première étape du processus d’analyse consiste à examiner la manière dont

les données sont collectées. Cela inclut tout, des fiches et des listes

manuscrites ou imprimées aux formulaires préimprimés et aux écrans de saisie

de données (tels que ceux utilisés dans un programme de base de données ou

un navigateur Web).
Commencez cette étape en examinant tous les éléments papier. Découvrez

quels types de documents l'organisation utilise pour enregistrer les données,

puis rassemblez un seul échantillon de chacun. Assemblez ces échantillons et

stockez-les dans un dossier pour une utilisation ultérieure dans le processus de

conception. Par exemple, supposons que l'organisation collecte les données

des fournisseurs sur des feuilles de papier dans un classeur. Parcourez les

premières pages du classeur jusqu'à ce que vous en trouviez une avec une

entrée aussi complète que possible. Quand tu as trouvé unéchantillon

approprié, faites-en une copie et enregistrez-la dans le dossier. Suivez ce

processus pour chaque type d’élément utilisé. La figure 6.1 montre deux

exemples de la manière dont l'organisation peut utiliser des éléments papier

pour collecter des données.

Figure 6.1 Exemples d'éléments papier utilisés pour collecter des données.

Ensuite, passez en revue tous les programmes informatiques que l'organisation

utilise pour collecter des données. L'objectif ici est de rassembler un ensemble

d'exemples de captures d'écran qui représentent la manière dont l'organisation

utilise ces programmes pour travailler avec les données. Un mot

d'avertissement : de nombreuses personnes ont découvert des moyens

uniques et ingénieux d'utiliser des programmes courants, tels que des

traitements de texte et des feuilles de calcul, pour collecter et gérer des

données. Assurez-vous de parler à quelqu'un qui connaît la façon dont les

ordinateurs sont utilisés au sein de l'organisation et déterminez quels

programmes l'organisation utilise pour gérer ses données.

Lorsque vous examinez chaque programme, recherchez un écran qui

représente le mieux la manière dont le programme collecte les données. Vous

recherchez des écrans similaires à ceux de la figure 6.2 .

Figure 6.2 Un écran de base de données typique et un écran de feuille de
calcul typique.
Le premier écran est typique de ceux que vous trouverez dans un programme

de base de données, et le deuxième écran est typique de ceux que vous

trouverez dans un tableur. Lorsque vous avez trouvé un exemple approprié,

créez une capture d'écran à l'aide de votre application de capture d'écran

préférée, collez-la dans un document de votre programme de traitement de

texte, indiquez le nom du programme source et la date à laquelle vous avez

créé la capture d'écran, puis imprimez le document. Continuez à revoir le

programme et répétez cette procédure si nécessaire. Répétez ensuite tout le

processus pour chaque programme. Après avoir imprimé des copies de toutes

les captures d'écran appropriées, assemblez-les et stockez-les dans un dossier

pour les utiliser ultérieurement dans le processus de conception.

Examinez maintenant les pages Web que l'organisation utilise pour collecter

des données via Internet. Les pages qui vous intéressent ressembleront

beaucoup aux formulaires de saisie de données que vous trouverez dans un

programme d'application de base de données. La figure 6.3 montre un exemple

d'une telle page.

Figure 6.3 Un exemple d'écran typique de saisie de données en ligne.

Vous pouvez suivre ici la même procédure d’examen que celle que vous avez

utilisée avec les programmes de candidature. Prenez une capture d'écran d'une

page Web donnée, collez-la dans un document de traitement de texte, indiquez

l'URL, le nom du programme et la date de la capture d'écran, puis imprimez-

la. Continuez à consulter les pages Web et répétez cette procédure si

nécessaire. Après avoir imprimé des copies de toutes les captures d'écran

appropriées, assemblez-les et stockez-les dans un dossier pour les utiliser

ultérieurement dans le processus de conception.

Assurez-vous de marquer clairement les dossiers contenant les échantillons

que vous avez collectés lors de votre analyse. Le peu de temps que vous

investissez pour organiser vos matériaux rapporte gros lorsque vous utilisez

ces matériaux pendant une phase complexe du processus de conception.

Examiner la façon dont les informations sont présentées

La deuxième étape du processus d'analyse consiste à examiner les différentes

manières dont l'organisation présente ses données sous forme

d'informations. Au cours de ce processus, vous examinerez des éléments tels

que des documents manuscrits, des impressions d'ordinateur, des

présentations sur écran et des pages Web.

Voici trois des méthodes de présentation les plus populaires que vous

rencontrerez au cours de ce processus.

1. Rapports : un rapport est tout document (dactylographié, imprimé ou

généré par ordinateur) utilisé pour organiser et présenter des données de

manière à ce qu'elles soient significatives pour la ou les personnes qui le

consultent. Bien que l'utilisation d'un traitement de texte, d'une feuille de

calcul ou d'un autre logiciel soit la méthode standard pour générer un

rapport, vous trouverez toujours certains rapports rédigés à la main.

2. Présentations sur écran (également appelées diaporamas) : ce type de

présentation intègre une série de diapositives qui abordent divers sujets de

manière organisée. Il est généralement créé avec un programme tel que

Microsoft PowerPoint, Google Slides ou Apple Keynote, et exécuté sur un

ordinateur.

3. Pages Web : de nombreuses organisations disposent d'une grande quantité

d'informations disponibles via des pages sur leurs sites Web. Une page Web

est utilisée à peu près de la même manière qu’un rapport et, en réalité, il ne

s’agit en réalité que d’un type de rapport différent.

Commencez cette étape en identifiant et en examinant chaque rapport que

l'organisation génère à partir de la base de données, que l'organisation

produise le rapport manuellement ou avec un programme

d'application. Rassemblez des échantillons de rapports et rassemblez-les dans

un dossier comme vous l'avez fait avec les éléments de l'étape

précédente. Dans l'ensemble, cette tâche est plus facile à réaliser à cette étape

qu'à l'étape précédente, car les membres de l'organisation connaissent

généralement les rapports qu'ils utilisent. Des exemplaires des rapports sont

généralement facilement disponibles et la plupart des rapports peuvent être

réimprimés si nécessaire. La figure 6.4 montre un exemple de rapport rédigé à

la main et de rapport généré à partir d'un programme de traitement de texte.

Figure 6.4 Un rapport manuscrit et un rapport généré par ordinateur.
Ensuite, examinez les présentations d’écran qui utilisent ou intègrent les

données de la base de données. Il n'est pas nécessaire de

revoir chaque présentation, mais vous devez examiner celles qui ont un impact

direct sur les données de la base de données. Par exemple, vous n'avez pas

besoin de revoir une présentation sur le nouveau produit de l'organisation si

elle ne tire aucune donnée de la base de données. D’un autre côté, une
présentation sur les statistiques de ventes qui intègre les données de la base

de données est une présentation que vous devez examiner.

Après avoir identifié les présentations que vous devez réviser, parcourez-les

attentivement et faites des captures d'écran des diapositives qui utilisent ou

intègrent des données de la base de données. Copiez les captures d'écran dans

un document de traitement de texte, imprimez le document, puis stockez-le

dans un dossier pour une utilisation ultérieure. (Écrivez le nom de la

présentation,son nom de fichier physique et la date à laquelle vous avez

capturé les captures d'écran sur le dossier ; vous devrez peut-être y revenir

plus tard.) Suivez cette procédure séparément pour chaque présentation. Vous

voulez vous assurer de ne pas combiner accidentellement deux ou plusieurs

présentations, car cette erreur conduirait inévitablement à une confusion

massive et entraînerait un énorme gâchis !

La figure 6.5 montre un exemple du type de diapositives que vous examinerez

au cours de cette révision.

Figure 6.5 Exemples de diapositives de présentation sur écran.

Réviser une présentation est difficile dans certains cas, et décider si vous devez

inclure une diapositive donnée comme exemple est une décision purement

discrétionnaire. Par conséquent, travaillez en étroite collaboration avec la

personne la plus familiarisée avec la présentation pour vous assurer que vous

incluez toutes les diapositives appropriées dans les exemples.

Enfin, examinez les pages Web qui tirent des informations directement de la

base de données. Effectuez cette révision de la même manière que la révision

des présentations à l’écran. Comme pour l’examen précédent, vous devez

examiner les pages Web qui ont un impact direct sur les données de la base de

données. Par exemple, vous n'avez pas besoin de consulter une page Web qui

fournit un historique de votre organisation, mais vous devez consulter une

page Web qui affiche des informations sur les employés régionaux.
Après avoir identifié les pages Web que vous devez consulter, prenez une

capture d'écran de chaque page. Copiez les captures d'écran dans un

traitement de textedocument, imprimez le document, puis stockez-le dans un

dossier pour une utilisation ultérieure. (Écrivez l'adresse URL et la date actuelle

sous chaque capture d'écran du document ; vous devrez peut-être vous référer

à nouveau à une page Web particulière ultérieurement.)

La figure 6.6 montre un exemple de page Web que vous examineriez au cours

de cet examen.

Figure 6.6 Exemple de page Web présentant des informations provenant

d'une base de données.

Essayez de travailler avec la ou les personnes qui ont créé et développé le site

Web de l'organisation. Ils peuvent vous faire gagner beaucoup de temps en

vous dirigeant vers les pages exactes que vous devez examiner pour cet

examen.
Mener des entretiens

Maintenant que vous avez une idée générale de la manière dont l'organisation

collecte et présente ses données, il est temps d'interroger les utilisateurs et la

direction pour déterminer comment l'organisation utilise ses données. Les

entretiens sont utiles dans la phase d’analyse pour ces raisons :

• Ils fournissent des détails sur les échantillons que vous avez assemblés lors

des examens précédents. Les discussions que vous avez eues avec les
utilisateurs et la direction lors des évaluations précédentes visaient

uniquement àidentifier (en termes généraux) la manière dont l’organisation

collecte et présente les données qu’elle utilise. Au cours de cette phase,

cependant, vous poserez des questions spécifiques sur les échantillons que

vous avez rassemblés lors de ces examens. Cela vous permettra de clarifier

les aspects d'un échantillon spécifique que vous considérez comme vagues

ou ambigus.

• Ils renseignent sur la manière dont l’organisation utilise ses données. Ces

entretiens vous fourniront des informations sur la manière dont les

utilisateurs travaillent quotidiennement avec les données de l'organisation

et sur la manière dont la direction utilise les informations basées sur ces

données pour gérer les affaires de l'organisation.

• Ils jouent un rôle déterminant dans la définition des structures préliminaires

des champs et des tables. Les réponses que vous recevrez des utilisateurs
et de la direction au cours de cette série d'entretiens vous aideront à

identifier les structures initiales de champs et de tables pour la base de

données.

• Ils aident à définir les futurs besoins d’information. Les discussions que vous

aurez avec les utilisateurs et la direction concernant la croissance future de

l'organisation révéleront souvent de nouveaux besoins en informations qui

doivent être pris en charge par la base de données.

Je ne saurais trop insister, et vous ne devez pas sous-estimer, l'impact des

entretiens sur la structure finale de la base de données et leur importance pour

la réussite du processus de conception de la base de données. Seuls des

entretiens complets vous aideront à garantir que la base de données que vous

concevez répond aux besoins d'information de votre organisation.

Techniques d'entretien de base

Vous devez d’abord apprendre quelques techniques d’entretien de base afin de

mener des entretiens réussis. J'aborde ce problème ici en vous fournissant un

ensemble de techniques fondamentales que vous pouvez utiliser pour mener

chaque entretien dans le cadre du processus de conception de base de

données. Ces techniques sont relativement faciles à apprendre et à appliquer,

et elles vous permettront d'obtenir les informations dont vous avez besoin pour

la tâche.

Vous exécuterez probablement ces techniques de manière stricte et mécanique

au fur et à mesure que vous commencez tout juste à les apprendre, mais vous

les appliquerez de manière plus instinctive et intuitive au fur et à mesure que

vous mènerez d'autres entretiens et acquerrez de l'expérience

supplémentaire. Mener un entretien est une compétence et, comme pour toute

autre compétence, vous atteindrez différents degrés d’expertise avec de la

patience et de la pratique.
L'importance des questions

Apprendre à poser une question est une compétence précieuse que vous

devrez apprendre et développer si vous voulez réussir à concevoir des bases

de données. C'est ce que vous utiliserez pour comprendre le fonctionnement

de votre entreprise (ou celle de votre client) et vous permettra de rassembler

les informations dont vous avez besoin pour développer les différentes

structures de la base de données. Et, comme vous l’avez peut-être déjà deviné,

c’est précisément la compétence requise pour mener les entretiens tout au

long de ce processus de conception. Je sais que cela peut sembler évident,

mais je ne peux tout simplement pas surestimer l'importance de cette

compétence.

Le processus d'entrevue

Vous utilisez des questions ouvertes et fermées tout au long d'un entretien, en

alternant entre chaque type au fur et à mesure que l'entretien progresse. Les

questions ouvertes sont de nature plus générale et vous permettent de vous

concentrer sur des sujets spécifiques, tandis que les questions fermées sont

plus spécifiques et vous permettent de vous concentrer sur des détails

particuliers d'un sujet donné. Par exemple, commencez l'entretien par quelques

questions ouvertes pour établir des sujets généraux de discussion, puis

sélectionnez un sujet et posez des questions plus spécifiques (fermées)

relatives à ce sujet. Vous pouvez commencer par poser à l’un des participants à

l’entretien une question ouverte telle que celle-ci :

« Comment définiriez-vous le travail que vous effectuez au quotidien ?

La plupart des participants utiliseront trois phrases ou plus pour répondre à ce

type de question. Il est parfaitement acceptable qu'un participant vous

fournisseavec une réponse longue et descriptive, car vous pouvez travailler

avec ce type de réponse plus facilement qu'avec une réponse laconique. Pour

illustrer ce point, supposons que le participant réponde à votre question de

cette manière :

« En tant que chargé de comptes, je suis responsable de dix clients. Chacun de

mes clients prend rendez-vous pour venir au showroom afin de voir la

marchandise que nous avons à offrir pour la saison en cours. Une partie de

mon travail consiste à répondre à toutes leurs questions sur nos produits et à

faire des recommandations concernant les articles les plus populaires. Une fois

qu'ils ont pris une décision sur la marchandise qu'ils souhaitent acheter, je

rédige une commande client pour le client. Ensuite, je remets la commande à

mon assistant, qui remplit rapidement la commande et l'envoie au client.

C'est une très bonne réponse. Le participant a non seulement répondu à votre

question, mais vous a également donné l'opportunité de commencer à poser

des questions de suivi. Sa réponse suggère également plusieurs sujets que

vous pourrez aborder plus tard dans l’entretien.

Note
Une réponse laconique, telle que « Je remplis les commandes des clients »,

vous fournit peu d'informations, vous devrez donc travailler un peu plus dur

avec le participant pour avoir une idée de ce qu'implique ce processus. Les

réponses laconiques indiquent généralement que le participant est simplement

nerveux ou mal à l'aise. Dans ce cas, vous pourriez le mettre à l'aise en

discutant quelques instants d'un sujet sans rapport ou en lui permettant de

choisir un sujet plus familier ou plus confortable comme point de départ.

Identifier les sujets

Lorsque vous posez chaque question ouverte, identifiez les sujets suggérés

dans la réponse à la question. Vous pouvez identifier les sujets en écoutant

les noms dans les phrases de la réponse. Les sujets sont toujours représentés

par des noms et identifient une personne, un lieu, une chose ou un événement

(quelque chose qui se produit à un moment donné). LàCertains noms,

cependant, représentent une caractéristique d'une personne, d'un lieu, d'une

chose ou d'un événement ; vous n'avez pas besoin de vous en préoccuper pour

l'instant. Par conséquent, assurez-vous d’écouter et de noter uniquement les

noms qui représentent spécifiquement une personne, un lieu, une chose ou un

événement. (Notez qu'il n'est pas nécessaire de noter plus d'une occurrence

d'un nom donné.) Vous pouvez vous assurer de tenir compte de chaque sujet

dont vous devez discuter en répertoriant les noms au fur et à mesure que vous

les identifiez. Dans l'exemple suivant, j'ai souligné les noms que vous pourriez

retenir en écoutant la réponse :

« En tant que représentant de compte , je suis responsable de

dix clients . Chacun de mes clients prend rendez-vous pour venir

au showroom afin de voir la marchandise que nous avons à offrir pour

la saison en cours . Une partie de mon travail consiste à répondre à toutes

leurs questions sur nos produits et à faire des recommandations concernant

les articles les plus populaires . Une fois qu'ils ont pris une décision sur la

marchandise qu'ils souhaitent acheter, je rédige une commande client pour le

client. Ensuite, je remets la commande à mon assistant , qui remplit

rapidement la commande et l'envoie au client.

Les noms que vous avez identifiés et répertoriés sur votre feuille de papier

deviennent votre liste de sujets. Vous ajouterez d’autres sujets à la liste au fur

et à mesure que vous continuerez à travailler sur le processus de

conception. Compilez cette liste avec soin et méthodique, car vous l'utiliserez

pour générer d'autres discussions au fur et à mesure de la progression de

l'entretien et pour vous aider à définir des tableaux plus tard dans le processus

de conception.

Voici les sujets (classés par ordre alphabétique) qui sont représentés dans la

réponse précédente :

Représentant de compteEmploi

Rendez-vousMarchandise

AssistantCommande client

ClientèleSaison

ArticlesSalle d'exposition

Vous pouvez désormais utiliser cette liste comme base pour d’autres questions

lors de l’entretien.

Note
Dans le reste du livre, je fais référence à l'ensemble de cette procédure sous le

nom de Technique d'identification du sujet .

Vérifiez que les noms que vous avez répertoriés sont de véritables sujets en

examinant chaque nom et en confirmant qu'il représente spécifiquement une

personne, un lieu, une chose ou un événement. Par exemple, « Représentant

de compte » représente bien une personne, et « Rendez-vous » est un nom qui

représente un événement ; dans ce cas, quelque chose qui se produit à un

moment donné.

Caractéristiques d'identification

Après avoir identifié les sujets suggérés dans la réponse, choisissez un sujet

particulier et commencez à poser des questions de suivi liées à ce sujet. Vous

utilisez cette ligne de questions pour obtenir autant d’informations détaillées

que possible sur le sujet que vous avez sélectionné. Assurez-vous que vos

questions de suivi sont plus spécifiques à mesure que vous progressez dans

cette partie de la discussion. La nature de vos questions de suivi dépendra des

réponses que vous recevrez du participant. Sur la base de notre exemple de

réponse, par exemple, vous pouvez poursuivre la discussion en posant des

questions plus spécifiques sur les commandes client, ou vous pouvez

commencer une toute nouvelle série de questions concernant les

clients. Supposons, pour l’instant, que vous posiez la question suivante pour en

savoir plus sur les commandes client :

« Parlons un instant des commandes client. Que faut-il pour terminer une

commande client pour un client ? »

Notez que cette question commence par une déclaration invitant le participant

à l'entretien à se concentrer sur un sujet particulier. Il s'agit d'une technique

que vous devez utiliser pour guider votre conversation après avoir sélectionné

un sujet spécifique à discuter. Notez également que la question est ouverte ;il

demande au participant des détails liés au sujet que vous avez sélectionné

(commandes clients) et vous permet d'établir l'orientation des réponses

ultérieures du participant.

Supposons maintenant que le participant donne la réponse suivante :

« Eh bien, je saisis d'abord toutes les informations sur le client, telles que son

nom, son adresse, son numéro de téléphone et son adresse e-mail. Ensuite,

j'entre les articles que le client souhaite acheter. Après avoir saisi tous les

éléments, je fais le total et j'ai terminé. Oh, j'ai oublié de mentionner que je

saisis le numéro de fax et l'adresse de livraison du client, s'il en a une.

Gardez à l'esprit la technique d'identification du sujet lorsque vous écoutez

cette réponse et notez tous les noms qui pourraient représenter une personne,

un lieu, une chose ou un événement sur votre liste de sujets.

Cependant, avec cette ligne de questions, vous serez plus intéressé à écouter

tous les détails concernant le sujet en discussion. Votre objectif ici est d’obtenir

autant de faits que possible sur le sujet. Vous vous intéressez maintenant aux

noms qui représentent les caractéristiques d’un sujet. Ils décrivent des aspects
particuliers de ce sujet. Vous pouvez identifier ces noms assez facilement car

ils sont généralement au singulier (« numéro de téléphone », « adresse »). En

revanche, les noms qui identifient des sujets sont généralement sous forme

possessive (« le numéro de téléphone du client », « l’ adresse de

l’entreprise »).
Essayez d'écouter autant de caractéristiques du sujet que possible. Dans

l'exemple suivant, j'ai souligné les noms que vous pourriez retenir en écoutant

la réponse :

« Eh bien, je saisis d'abord toutes les informations sur le client, telles que

le nom , l'adresse , le numéro de téléphone et l'adresse e-mail du

client . Ensuite, j'entre les articles que le client souhaite acheter. Après avoir

saisi tous les éléments, je fais le total et j'ai terminé. Oh, j'ai oublié de

mentionner que je saisis le numéro de fax et l'adresse de livraison du client ,

s'il en a une.

Au fur et à mesure que vous identifiez les noms appropriés dans une réponse,

énumérez-les sur une feuille de papier ; cela devient votre liste de

caractéristiques . Vous ajouterez d’autres caractéristiques à la liste au fur et à

mesure du processus de conception et vous utiliserez cette liste plus tard

lorsque vous déterminerez les champs de la base de données. Utilisez

une feuille de papier séparée pour la liste des caractéristiques. Ne listez pas
les matières et les caractéristiques sur une même feuille ! (La raison pour
laquelle vous les conservez sur des listes différentes deviendra claire lorsque

vous commencerez à définir des tables pour la base de données au chapitre 7 ,

« Établir des structures de tables . »)

Voici les caractéristiques (affichées par ordre alphabétique) qui sont

représentées dans la réponse précédente :

Nom de l'adresseTotaux

Adresse e-mailNuméro de téléphone

Numéro de faxadresse de livraison

Ceci constitue la liste des caractéristiques du sujet en discussion. Ces

caractéristiques deviendront éventuellement des champs dans la base de

données.
 Note

Dans le reste du livre, je fais référence à l'ensemble de cette procédure sous le

nom de Technique d'identification des caractéristiques .

Vérifiez que les noms que vous avez répertoriés sont de véritables

caractéristiques en confirmant qu'ils représentent des aspects particuliers de

ce sujet. Par exemple, « nom » décrit une caractéristique du sujet « client » et

« Adresse de livraison » représente une autre caractéristique du sujet « client

».

Après avoir fini de discuter d'un sujet particulier, passez au sujet suivant de

votre liste de sujets et commencez le même schéma de questions. Commencez

par des questions ouvertes, identifiez les sujets suggérés dans les réponses,

posez des questions plus spécifiques au fur et à mesure de la

discussion.progresse et identifie le plus grand nombre possible de

caractéristiques du sujet. Continuez ce processus de manière méthodique

jusqu'à ce que vous ayez discuté de tous les sujets de votre liste.

Vous devez apprendre la technique d'identification du sujet et la technique

d'identification des caractéristiques de manière aussi approfondie que possible,

car vous les utiliserez lors de vos entretiens avec les utilisateurs et la direction

et lorsque vous identifierez les champs et les tables pour la structure initiale de

la base de données. Notez qu’il deviendra plus facile de distinguer les sujets et

les caractéristiques dans votre esprit à mesure que vous acquerrez de

l’expérience dans l’utilisation de ces techniques. Ils finiront par devenir plus

instinctifs et intuitifs.
Avant de commencer le processus d'entrevue. . .

Vous pouvez utiliser les techniques que vous venez d'apprendre dans cette

section pour les entretiens avec les utilisateurs et les entretiens avec la

direction. Les seules différences entre les deux séries d’entretiens résident

dans le sujet et le contenu des questions.

Le processus d'entretien implique deux séries de discussions : l'une avec les

utilisateurs et l'autre avec la direction. Vous parlerez d'abord aux utilisateurs,

car ils représentent la « première ligne » de l'organisation. Ils ont l'image la

plus claire des détails liés aux opérations quotidiennes de l'organisation. De

plus, les informations que vous collectez auprès des utilisateurs devraient vous

aider à comprendre les réponses que vous recevez de la direction.

Interviewer les utilisateurs

La première partie du processus d'entretien consiste à mener des entretiens

avec les utilisateurs. Les entretiens se concentrent sur ces quatre questions :

1. Les types de données que les utilisateurs utilisent actuellement

2. Comment les utilisateurs utilisent actuellement leurs données

3. La collection d'échantillons que vous avez rassemblés au cours des deux

premières étapes de l'analyse

4. Et les types d’informations dont les utilisateurs ont besoin pour leur travail

quotidien
Parce que ces questions sont à la fois centrées sur les données et sur

l’information, vous devez être certain de comprendre et de toujours garder à

l’esprit la différence entre les données et les informations. Rappelez-vous

du chapitre 3 , « Terminologie », que les données sont les valeurs que vous

stockez dans la base de données et que les informations sont des données que

vous traitez d'une manière qui les rend significatives et utiles lorsque vous

travaillez avec elles ou les visualisez. Garder ces définitions à l’esprit vous

aidera à vous concentrer correctement sur chaque question et à mener chaque

segment de l’entretien avec succès.

Examen du type et de l'utilisation des données

Vous pouvez généralement discuter des deux premiers sujets en même temps

si vous formulez soigneusement vos questions au début de l'entretien. Votre

objectif pour cette partie de l'entretien est d'identifier les types de données

que les utilisateurs utilisent actuellement et comment ils utilisent ces données

pour soutenir leur travail. Vous utiliserez ces informations plus tard dans le

processus de conception pour vous aider à définir les structures des champs et

des tables. Utilisez les exemples de collecte de données et de représentation

des données pour vous aider à formuler des questions sur les données de

l'utilisateur. (Cependant, ne discutez pas encore des exemples ; vous devez les

traiter séparément.) Au cours de cette discussion, vous commencerez par des

questions ouvertes, identifierez les sujets dans les réponses, puis utiliserez des

questions de suivi spécifiques pour identifier les caractéristiques de chaque

sujet.

Au début de l’entretien, interrogez chaque participant sur le travail qu’il

effectue au quotidien. Après qu'un participant ait fourni une description globale

du travail qu'il effectue, demandez-lui d'expliquer son travail plus en

détail. Peut-être pourra-t-il vous guider dans le travail qu'il effectue au

quotidien.
Voici un exemple de conversation typique qui se produit pendant cette partie

de l'entretien. J'ai souligné les noms qui devraient attirer votre attention.

INTERVIEWER :« Quel genre de travail faites-vous au quotidien ? »

PARTICIPANT :«J'accepte les demandes d'aménagement du territoire soumises

par diverses personnes , je les connecte et je fixe une date d'audience avec

l'examinateur d'audience. J’aide également les candidats s’ils ont des questions

concernant une candidature spécifique.

INTERVIEWER :« Parlons un instant des candidatures. Quels types de faits sont

associés à une demande ? »

PARTICIPANT :« Il y en a un certain nombre, en fait. Il existe des faits

concernant le type et le nom de la demande, sa désignation et son adresse ,

ainsi que son emplacement .

INTERVIEWER :"Parlez-moi des faits concernant le type et le nom de

l'application."

PARTICIPANT :"Il y a quatre choses que nous enregistrons : le type de

demande , le nom du lotissement , le but du projet et une description du

projet."

Notez comment l'intervieweur démarre la discussion avec une question

ouverte. Pendant que le participant répond, l'intervieweur utilise la technique

d'identification du sujet pour identifier les sujets dans la

réponse. L'intervieweur choisit ensuite un sujet particulier et utilise une autre

question ouverte pour attirer l'attention du participant sur ce sujet. Étant

donné que la réponse suivante du participant est de nature générale,

l'intervieweur se concentre sur un aspect particulier du sujet et utilise une

question de suivi plus spécifique pour obtenir une réponse détaillée de la part

du participant.
L'intervieweur peut continuer à affiner ses questions au fur et à mesure que la

discussion progresse. Au fur et à mesure que le participant répond à chaque

question, l'intervieweur continue d'utiliser le formulaire Caractéristiques-

Identification.Technique pour identifier les caractéristiques du sujet qui

apparaissent dans la réponse. Après avoir identifié toutes les caractéristiques

du sujet, l'intervieweur passe au sujet suivant et recommence tout le

processus. Il continuera de cette manière jusqu'à ce qu'il ait couvert toute sa

liste de sujets. Vous passerez par exactement le même processus lorsque vous

agirez en tant qu’intervieweur.

Note

Le dialogue dans l'exemple précédent et dans les exemples tout au long du

livre est simpliste par conception ; cela s'applique également à tous les

exemples de questions que je propose lors de ma discussion sur le processus

d'entretien. Ils sont simplement le véhicule à travers lequel je présente une

compétence ou une technique spécifique. En tant que tel, ne vous préoccupez

pas trop du dialogue lui-même ou de la question elle-même ; concentrez-vous

plutôt sur la façon dont il illustre la compétence ou la technique dont je parle

en ce moment. Les exemples vous seront plus bénéfiques si vous les voyez

sous cet angle.

Examen des échantillons

La prochaine série de discussions se concentre sur tous les échantillons que

vous avez rassemblés plus tôt dans le processus d'analyse. Vos objectifs lors de

ces discussions sont d'identifier comment les objets représentés par les

échantillons sont utilisés, de clarifier les aspects des échantillons que vous ne

comprenez pas et d'attribuer une description à chaque échantillon.

Il devrait être relativement facile pour vous de parler des échantillons aux

participants maintenant que vous avez une idée des données que les

participants utilisent quotidiennement. Commencez la conversation en posant

des questions sur un échantillon spécifique. La figure 6.7 montre un exemple

d'échantillon de collecte de données que vous pouvez utiliser comme point de

départ.

Figure 6.7 Un échantillon de collecte de données.

Note

La déclaration que j'ai faite à propos des exemples de dialogue s'applique

également à cette figure et à de nombreuses autres figures du livre. Ces

chiffres sont simplement le véhicule à travers lequel je présente une

compétence ou une technique spécifique. Utilisez la même approche que celle

que j'ai suggérée pour les exemples de dialogue, car elles vous seront plus

bénéfiques.
Révisez vos notes des discussions que vous avez eues au début de l'entretien

avant de poser votre première question. Vous souhaitez déterminer si tout ce

dont vous avez déjà discuté est pertinent pour l'échantillon dont vous êtes sur

le point de discuter. Par exemple, lors d'une discussion précédente, un

participant a indiqué qu'une partie de son travail consiste à suivre tous les

clients de l'organisation. En utilisant cette déclaration comme point de départ,

vous pouvez lui demander comment il utilise cet échantillon particulier de

collecte de données pour effectuer cette tâche.

« Vous avez mentionné lors d'une discussion précédente que vous gardiez une

trace de tous les clients. Comment cet écran vous aide-t-il à accomplir cette

tâche ? »

C'est une question bien formulée. Cela commence par une déclaration qui se

concentre sur un sujet particulier, puis se poursuit en attirant l'attention du

participant sur l'échantillon. La question est suffisamment ouverte pour

susciter une réponse claire et complète.

Supposons maintenant que le participant fournisse cette réponse :

"Cet écran me permet de saisir de nouveaux clients, ainsi que de modifier et de

conserver toutes les informations dont nous disposons sur les clients

existants."

Si cette réponse répond à la question à votre entière satisfaction, utilisez-la

comme base pour une description de l'échantillon. Sinon, continuez avec une

ligne de questions appropriée jusqu'à ce que le participant identifie clairement

le but et l'utilisation de l'échantillon. Vous devez fournir des descriptions pour

tous vos échantillons, car vous les réutiliserez plus tard dans le processus de

conception.
La description d'un échantillon doit être succincte, mais suffisamment claire

pour indiquer le but de l'échantillon et la manière dont il est utilisé. Écrivez la

description sur un bout de papier et joignez-la à l’échantillon. Voici un exemple

de description que vous pourriez utiliser pour l'exemple de la figure 6.7 :

Cet écran est utilisé pour collecter et conserver toutes les données client.

Vous devez comprendre l’échantillon aussi complètement que possible afin de

pouvoir rédiger une description claire et concise. Si vous ne comprenez pas

certains aspects d'un échantillon donné, demandez au participant de les

clarifier pour vous. Par exemple, supposons que vous travaillez avec l'exemple

de rapport présenté dans la figure 6.8 .

Figure 6.8 Un exemple de rapport.

Si vous ne savez pas ce que représente l'abréviation « SRP », assurez-vous que

le participant vous la clarifie ; ne faites jamais d'hypothèses ou de

suppositions. Cela peut faire perdre un temps et des efforts précieux plus tard

dans le processus si votre hypothèse ou supposition s’avère incorrecte.

Lorsque vous rédigez des descriptions pour chacun des échantillons, vous

aurez peut-être du mal à rédiger une description pour un

échantillon complexe . Un échantillon est complexe s’il représente plus d’un

sujet. L'échantillon de la figure 6.8 , par exemple, ne couvre qu'un seul sujet :

les produits. L'échantillon de la figure 6.9 couvre cependant au moins trois

sujets : les services médicaux, les services infirmiers et les patients. Vous

devrez souvent travailler un peu plus dur pour déterminer le but et l’utilisation

d’un échantillon complexe. Dans certains cas, vous devrez utiliser la technique

d'identification du sujet pour déterminer quels sujets sont représentés.

Disons que vous travaillez avec l'exemple de rapport présenté dans la figure

6.9 et que vous avez des questions concernant les services infirmiers. Vous

vous demandez si l'organisation utilise ce rapport comme moyen indirect de

maintenir à jour une liste de services infirmiers. Une question qui suscite une

réponse par oui ou par non de la part d'un participant ne vous aidera pas

beaucoup, vous devez donc utiliser une question ouverte qui suscitera une

réponse plus informative. Vous pouvez commencer votre discussion sur cet

exemple par cette question :

« Quels services infirmiers fournissez-vous en plus de ceux répertoriés dans cet

échantillon ? »
Figure 6.9 Un exemple d'un exemple de rapport complexe.

Ce type de question donne au participant la possibilité de vous fournir une

réponse détaillée ; de plus, vous vous êtes donné la possibilité de poser des

questions de suivi comme le justifie la réponse du participant. Pour continuer

l'exemple, disons que vous recevez la réponse suivante :

« Nous fournissons divers services spécialisés pour les patients les plus

complexes. Vous voyez uniquement les services généraux sur ce

rapport. Cependant, je peux vous montrer une liste complète de nos services

que Katherine gère sur son ordinateur.

Vous pouvez poursuivre le processus de rédaction de la description de

l'échantillon si cette réponse clarifie le point en question et que vous

comprenez maintenant l'objectif de cet exemple de rapport ; sinon, continuez à

poser des questions de suivi jusqu'à ce que tout soit expliqué à votre

satisfaction.

Examen des exigences en matière d'informations

Le dernier problème dont vous discuterez avec les utilisateurs concerne leurs

besoins en informations. Les objectifs de cette discussion sont de déterminer si

les utilisateurs individuels reçoivent des informations basées sur des données

qu'ils ne contrôlent pas ou ne conservent pas directement, de déterminer de

quels types d'informations supplémentaires ils ont besoin et de déterminer de

quels types d'informations ils peuvent avoir besoin à l'avenir. . Vous utiliserez

les informations que vous collectez au cours de cette discussion plus tard dans

le processus de conception pour vous aider à définir et à vérifier les structures

de champs et de tables. Vous pouvez également utiliser ces informations

comme un autre moyen de déterminer si vous avez accidentellement oublié

quelque chose lors des discussions précédentes.

Exigences actuelles en matière d'information

Les utilisateurs reçoivent généralement les informations qu'ils utilisent via

divers rapports. Par conséquent, la meilleure façon de commencer cette

discussion est d’examiner les exemples de rapports. Cette fois-ci, cependant,

vous n'êtes pas aussi préoccupé par la manière dont les rapports sont utilisés

que par les données sur lesquelles ils sont basés. Il est assez courant que les

informations contenues dans certains rapports qu'un utilisateur reçoit soient

basées sur des données qu'il ne crée pas et ne gère pas personnellement. Dans

cette situation, vous devez déterminer l'origine de ces données afin de pouvoir

identifier toutes les données utilisées par un utilisateur, qu'il les utilise

directement ou indirectement.

Sélectionnez un rapport parmi les exemples de rapport et travaillez avec l’un

des participants pour déterminer quelles données sont utilisées pour produire

le rapport. Demandez-lui s'il crée et conserve les données sur lesquelles le

rapport est basé. Vous pouvez passer à l'échantillon suivant s'il répond « oui »,

mais vous devrez identifier l'origine des données s'il répond « non ». Voici un

exemple qui illustre ce processus.

Supposons que vous ayez une assistante nommée Kira qui entame une

discussion avec une participante nommée Joan concernant l'exemple de

rapport présenté dans la figure 6.10 .

Figure 6.10 Un exemple de rapport.

Alors que Kira entame la conversation, Joan mentionne qu'elle travaille dans le

département marketing. Lorsque Kira pose pour la première fois des questions

sur l'exemple de rapport,Joan indique qu'elle le reçoit tous les lundis

matin. Alors Kira lui pose la question suivante :

« Fournissez-vous les données utilisées pour générer ce rapport ? »

Son prochain plan d'action dépend de la réponse de Joan. Kira peut passer à

l'échantillon suivant si la réponse de Joan est oui ; cependant, ce serait une

bonne idée que Kira pose une question complémentaire pour s'assurer que la

réponse de Joan est vraie.

« Est-ce que vous saisissez et conservez personnellement ces données

quotidiennement ?

Si la réponse de Joan est toujours oui, Kira peut définitivement passer à

l'échantillon suivant.
D'un autre côté, si la réponse de Joan à la question initiale est non, Kira devra

poser quelques questions complémentaires. Tout d'abord, elle demandera à

Joan si elle fournit des données au rapport. Si tel est le cas, Kira déterminera

alors quelles données Joan soumet spécifiquement. Kira demandera ensuite si

Joan connaît la source des données restantes.

Pour continuer l'exemple, disons que la réponse de Jeanne à la question initiale

est « non » et que le dialogue suivant a lieu après sa réponse :

KIRA :« Pouvez-vous alors me dire s’il existe des données que vous contribuez

au rapport ? »

J OAN :"Je fournis le nom et le numéro de téléphone du client."

KIRA :« Pouvez-vous me dire qui fournit le type de client et la date du dernier

achat ? »

J OAN :«Je n'en suis pas vraiment sûr, mais. . .»

KIRA :"Avez-vous une idée d'où viennent ces objets?"

J OAN :« En fait, oui. Ils viennent du service commercial.

KIRA :"Sa sonne bien pour moi. Je vais noter cela sur cet échantillon, puis nous

pourrons passer au suivant.

Notez qu'au début du dialogue, Kira essaie d'abord de déterminer si Joan

soumet des données au rapport. Quand Joan révèle qu'elleapporte deux des

éléments du rapport, Kira pose ensuite une question de suivi pour voir si Joan

peut identifier la source des données restantes. Dans ce cas, il suffit de deux

questions bien formulées pour trouver la réponse. Si Joan ne pouvait pas

répondre aux deux dernières questions, Kira devrait poursuivre son enquête

avec les autres participants.

Vous êtes sûr d'obtenir toutes les informations dont vous avez besoin sur vos

échantillons de rapport si vos discussions progressent de la même manière que

le dialogue précédent. N'oubliez pas : les questions de suivi constituent une

partie cruciale de la conversation. Vous devez formuler correctement vos

questions pour obtenir les types de réponses dont vous avez besoin de la part

des participants.

Exigences en matière d'informations supplémentaires

Le prochain sujet de discussion concerne les exigences en matière

d’informations supplémentaires . L'objectif ici est de déterminer si les

utilisateurs ont besoin d'informations supplémentaires qui ne leur sont pas

fournies actuellement. Si tel est le cas, vous devez identifier les informations

supplémentaires dont ils ont besoin, puis définir de nouvelles structures de

données pour prendre en charge ces informations supplémentaires plus tard

dans le processus de conception.

Démarrez cette conversation en demandant aux participants d'examiner les

rapports qu'ils reçoivent actuellement. Demandez-leur s'il y a d'autres

informations qu'ils aimeraient voir dans leurs rapports. Ensuite, demandez-leur

de discuter des informations supplémentaires, des rapports que ces

informations affecteront et de la raison pour laquelle ils pensent que ces

informations sont nécessaires. Déterminez ensuite si les informations

supplémentaires représentent de nouveaux sujets ou de nouvelles

caractéristiques. Si tel est le cas, identifiez chaque nouvel élément et ajoutez-

le à la liste appropriée. Enfin, examinez les commentaires des participants et

déterminez s'il y a d'autres questions dont vous devez discuter avec eux en ce

qui concerne les rapports. Voici un exemple qui illustre le processus.

Supposons que vous commencez cette discussion et que vous venez de

demander aux participants d'examiner les exemples de rapports qu'ils utilisent

actuellement. L'un des participants examine l'exemple de rapport présenté à la

figure 6.11 .

Figure 6.11 Exemple de rapport examiné par un participant.

Vous demandez maintenant à cette participante de noter les informations

supplémentaires qu'elle souhaite voir sur le rapport et de fournir une brève

déclaration indiquant pourquoi ces informations sont nécessaires. La

manière exacte dont elle prend les notes n'a pas vraiment d'importance , du
moment qu'elles sont claires et jointes au rapport de manière évidente. Dans

ce cas-ci, elle décide d’utiliser de grandes notes autocollantes pour

documenter ses commentaires. Elle a spécifié deux nouveaux champs qu'elle

souhaite ajouter au rapport, ainsi que la raison de leur inclusion. Elle a

également suggéré des emplacements possibles pour les champs en écrivant

leurs noms sur le rapport lui-même. La figure 6.12 montre l'exemple de rapport

avec ses commentaires.

Figure 6.12 Un exemple de rapport avec les commentaires d'un participant.

Ensuite, déterminez si de nouveaux sujets ou de nouvelles caractéristiques

sont représentés dans les informations supplémentaires. Gardez à l’esprit la

technique d’identification du sujet et la technique d’identification des

caractéristiques lorsque vous vous référez aux commentaires joints au

rapport. Voici un exemple de la façon dont vous appliquez ces techniques au

premier commentaire de la figure 6.12 .

Note

À partir de maintenant, je soulignerai toujours les noms dans un exemple qui

devrait attirer votre attention, le cas échéant.

« Pouvons-nous inclure le nom du fournisseur ? Cela faciliterait l’identification

d’un produit spécifique .

Ici, vous avez identifié à la fois un sujet et une caractéristique. (Notez que le

sujet et la caractéristique ne sont pas directement liés : le « nom du

fournisseur » est une caractéristique d'un fournisseur, pas d'un produit. Il n'y a

pas de problème ici, mais vous devez être conscient que cette apparente

inadéquation des sujets et des caractéristiques est typique. Vous aborderez ce

problème plus tard dans le processus de conception.) Maintenant, vérifiez votre

liste de sujets et votre liste de caractéristiques pour déterminer si vous avez

déjà pris en compte ces éléments. Si c’est le cas, passez au commentaire

suivant et répétez cette procédure.

Si vous découvrez un nouveau sujet, ajoutez-le à votre liste de sujets puis

identifiez autant de caractéristiques que possible. Lorsque vous avez terminé,

ajoutez ces éléments à votre liste de caractéristiques, passez au commentaire

suivant et répétez toute la procédure. Cependant, dans de nombreux cas, vous

identifierez uniquement de nouvelles caractéristiques. Ne vous inquiétez

pas. Les gens souhaitent souvent ajouter à un rapport des éléments

caractéristiques de sujets déjà représentés par les informations contenues dans

le rapport.

Enfin, réexaminez chaque rapport et déterminez si vous avez des questions ou

des préoccupations concernant les notes prises par les participants. Par

exemple, vous pouvez remettre en question la raison qui sous-tend la

conviction d'un participant selon laquelle des champs spécifiques sont

nécessaires dans un rapport donné. Ou vous vous demandez peut-être

pourquoi un autre participant souhaite exclure certains champs deun de ses

rapports. Vous voulez absolument vous assurer que les champs qu'il souhaite

exclure sont vraiment inutiles et que leur suppression n'aura pas d'effet négatif

sur les informations que le rapport fournit à d'autres personnes. Dans les deux

cas, l'inclusion ou l'exclusion de champs affectera la structure finale de la base

de données.
Si un rapport contient une ou plusieurs remarques préoccupantes, examinez-le

avec le participant approprié et réglez autant de problèmes que possible. Vous

pouvez généralement résoudre toutes vos préoccupations avec quelques

questions simples, mais dans certains cas, la résolution de certains problèmes

ne deviendra apparente que plus tard dans le processus de conception. Par

exemple, vous avez peut-être remarqué que certains champs apparaissent

dans deux rapports ou plus. Il est difficile de déterminer si les champs sont

inutilement dupliqués tant que vous n'avez pas commencé à définir les

structures des champs et des tables. Lorsque vous rencontrez un problème

difficile à résoudre à l’heure actuelle, prenez-en note et mettez le rapport de

côté pour un examen ultérieur.

Exigences futures en matière d'information

Le dernier sujet de discussion concerne les futurs besoins d’information. Votre

objectif ici est d'identifier les informations que les participants estiment

nécessaires à recevoir au fur et à mesure de l'évolution de l'organisation. Après

avoir identifié ces futurs besoins en informations, vous pouvez vous assurer

que vous définissez les structures de données nécessaires pour prendre en

charge ces informations.

Vous devez d’abord vous assurer que chaque participant a une idée de la façon

dont l’organisation évolue. La nature de l'évolution de l'organisation

déterminera les nouvelles informations dont les participants auront besoin. Si

plusieurs personnes ne connaissent pas ces problématiques, vous devrez

obtenir cette information auprès de la direction puis la relayer aux participants

avant la discussion. Vous pouvez commencer la conversation une fois que tout

le monde est familiarisé avec ces sujets.

Commencez la discussion en demandant aux participants de réfléchir à

l’évolution future de l’organisation et à la façon dont elle pourrait affecter leur

travail quotidien. Vous constaterez souvent que certains participants auront du

mal à imaginer ce scénario. Lorsque cela se produit, posez des questions

comme celles-ci pour les aider à concentrer leurs pensées :

Comment l’évolution de l’organisation affectera-t-elle la quantité d’informations

dont vous aurez besoin pour faire votre travail ?

Pensez-vous que vous aurez besoin de types d'informations supplémentaires

pour mener à bien vos tâches efficacement à mesure que l'organisation

évolue ?

Comment l’évolution de l’organisation va-t-elle augmenter le temps que vous

consacrez à vos tâches quotidiennes ?

Pouvez-vous prédire de quels types (catégories, et non éléments spécifiques)

de nouvelles informations vous aurez besoin pour exercer vos fonctions à

mesure que l'organisation évolue ?

Anticipez-vous un besoin d'informations nouvelles si vos tâches sont accrues en

raison de l'évolution de l'organisation ?

Gardez à l'esprit que la plupart des réponses des participants seront basées

sur des spéculations. Il n'existe aucun moyen précis pour eux de prédire de

quels types d'informations ils auront réellement besoin jusqu'à ce que

l'évolution de l'organisation se produise. Cependant, si vous pouvez anticiper

leurs besoins hypothétiques en informations, vous pouvez vous y préparer en

définissant à l’avance les structures de données nécessaires.

Pendant que les participants répondent, gardez à l'esprit la technique

d'identification du sujet afin de pouvoir identifier tout nouveau sujet, puis les

ajouter à votre liste de sujets. Gardez à l'esprit la technique d'identification des

caractéristiques afin de pouvoir écouter tout nouveau détail concernant des

sujets existants ou nouveaux et les ajouter à votre liste de caractéristiques.

Vous pouvez esquisser des idées de nouveaux rapports ou formulaires de saisie

de données pour aider les participants à visualiser les types d'informations

dont ils pourraient avoir besoin à l'avenir. Ces croquis peuvent ensuite vous

aider à identifier de nouveaux sujets ou caractéristiques que la structure de la

base de données doit aborder. Si vous créez plusieurs ébauches d'exemples de

rapports, assurez-vous d'assemblerdans un dossier séparé et clairement

identifié. Codez ensuite chaque révision afin de pouvoir la comparer avec les

révisions précédentes. La figure 6.13 montre un exemple de conception

préliminaire pour un futur rapport.

Figure 6.13 Un exemple de conception d'un nouveau rapport.

Poursuivez la conversation avec les utilisateurs jusqu'à ce que vous soyez

convaincu d'avoir répondu au plus grand nombre possible de besoins

d'informations futurs des participants. Une fois la discussion terminée, vous

êtes prêt à mener des entretiens avec la direction.

Note

Vous pouvez également utiliser toutes les techniques que vous avez apprises

dans cette section pour les entretiens de direction. La section suivante est donc

un peu plus courte et plus concise.

Gestion des entretiens

La deuxième partie du processus d'entretien consiste à interroger le personnel

de direction. Cette série d’entretiens se concentre sur ces questions :

1. Les types d’informations que les gestionnaires reçoivent actuellement

2. Les types d’informations supplémentaires dont ils ont besoin

3. Les types d’informations dont ils estiment avoir besoin

4. Leur perception des besoins globaux en information de l'organisation

Note

Dans le reste du livre, j'utilise le terme gestion pour désigner la ou les

personnes contrôlant ou dirigeant l'organisation.

Examen des exigences actuelles en matière d'information

Vos objectifs au cours de la première partie de cet entretien sont d'identifier les

informations que la direction reçoit régulièrement et de déterminer si elle reçoit

des rapports qui ne sont pas représentés dans votre groupe d'échantillons de

rapports.

Au début de l'entretien, interrogez les participants sur le travail qu'ils

effectuent et les responsabilités associées au poste. Les managers ont

généralement un certain nombre de problèmes en tête, ces questions aideront

donc à concentrer l’attention sur les problèmes en question. Les réponses vous

donneront une idée de la manière dont les gestionnaires pourraient utiliser les

informations contenues dans les rapports qu'ils reçoivent et vous donneront

une perspective sur la nécessité de ces informations.

Ensuite, demandez aux participants s’ils utilisent l’un des rapports de votre

collection d’échantillons de rapports. Passez à l'étape suivante s'ils déclarent

qu'ils n'utilisent aucun des rapports ; sinon, examinez chaque rapport et

demandez-leur de vous aider à identifier d'autres sujets que vous auriez pu

négliger auparavant. Gardez à l’esprit la technique d’identification du sujet

pour vous aider dans ce processus. Si le responsable identifie un nouveau

sujet, ajoutez-le à votre liste de sujets et appliquez la technique d'identification

des caractéristiques pour déterminer les caractéristiques du sujet. Ajoutez les

nouvelles caractéristiques à votre liste de caractéristiques. Répétez toute cette

procédure pour chaque exemple de rapport.

Poursuivez la discussion en demandant aux participants s'ils reçoivent des

rapports qui ne sont pas représentés dans vos échantillons de rapports. Si la

réponse est « oui », obtenez un échantillon de chaque nouveau rapport et

examinez-le avec le participant. Encore une fois, gardez à l'esprit la technique

d'identification du sujet et la technique d'identification des caractéristiques

pour identifier les sujets (et leurs caractéristiques associées) représentés dans

le rapport, puis ajoutez les sujets et les caractéristiques à leurs listes

respectives. Enfin, joignez une description au rapport et ajoutez-la à votre

collection d'échantillons de rapport. Répétez cette procédure jusqu'à ce que

vous ayez pris en compte chaque nouveau rapport.

Examen des exigences en matière d'informations supplémentaires

Le prochain sujet de discussion concerne le besoin d'

informations supplémentaires de la direction . Votre objectif est de déterminer

si cela nécessite des informations supplémentaires qui manquent actuellement

dans les rapports qu'ils reçoivent. Si vous concluez que tel est le cas, vous

devez identifier ces informations supplémentaires. Vous définirez ensuite de

nouvelles structures de données (le cas échéant) pour prendre en charge ces

informations plus tard dans le processus de conception. Cependant, vous

pouvez passer à la partie suivante de l'entretien si la direction n'a pas besoin

d'informations supplémentaires.

Vous utilisez les mêmes techniques pour cette discussion que celles que vous

avez utilisées pour ce segment des entretiens avec les utilisateurs. Voici les

étapes que vous suivrez.

1. Examinez à nouveau les exemples de rapports avec les participants et

demandez-leur s'il y a des informations supplémentaires qu'ils aimeraient

inclure dans l'un des rapports.

2. Demandez aux participants de noter les informations supplémentaires, y

compris les raisons pour lesquelles ils estiment que cela est nécessaire, sur

les rapports appropriés. N'oubliez pas que la manière dont les participants

prennent leurs notes n'a pas d'importance tant qu'elles sont claires, visibles

et jointes au rapport approprié.

3. Identifiez de nouveaux sujets ou caractéristiques dans les informations et

ajoutez-les à la liste appropriée.

4. Examinez les rapports et discutez de toutes vos préoccupations à leur sujet

avec les participants. Une fois vos préoccupations résolues, ce processus est

terminé.

Examen des exigences futures en matière d'information

Les besoins futurs en matière d'information constituent le prochain sujet de

discussion. Votre objectif ici est de déterminer de quoi la gestion de

l’information prévoit avoir besoin à l’avenir. Après avoir identifié ces exigences,

vous pouvez vous assurer que des structures de données sont en place pour

prendre en charge ces informations lorsque le besoin s'en fait sentir.

Au début de la discussion, demandez aux participants de réfléchir à la façon

dont l’organisation évolue actuellement. Demandez-leur ensuite comment

cette évolution affectera les informations dont ils ont besoin pour prendre des

décisions judicieuses et comment elle influencera la façon dont ils guident ou

dirigent l'organisation. N'oubliez pas que leurs réponses seront basées sur des

spéculations, comme ce fut le cas pour les questions similaires que vous avez

posées aux utilisateurs ; la direction n'a aucun moyen de prédire avec précision

ses besoins futurs tant que l'organisation n'a pas réellement commencé à

évoluer. (C'est toujours une bonne idée, cependant, de planifier l'avenir autant

que possible.) Gardez à l'esprit la technique d'identification du sujet et la

technique d'identification des caractéristiques pour identifier de nouveaux

sujets et caractéristiques dans les réponses des participants, puis ajoutez les

nouveaux éléments. (le cas échéant) aux listes appropriées.

Ensuite, faites des croquis de tout nouveau rapport que les participants

pourraient avoir en tête. Identifiez de nouveaux sujets et caractéristiques dans

chaque rapport et ajoutez-les aux listes appropriées. Rassemblez ces nouveaux

rapports dans un dossier clairement identifié et ajoutez-le à votre collection

d'échantillons.

Vous êtes prêt à passer au dernier sujet lorsque vous avez pris en compte

autant de besoins d'information futurs de la direction que possible.

Examen des exigences générales en matière d'information

Le dernier sujet de discussion concerne les besoins globaux d'information de

l'organisation. De l’avis de la direction, de quelle classe générique

d’informations l’organisation a-t-elle besoin ? Votre objectif ici est de découvrir

s'il existe des données que l'organisation doit conserver et qui n'ont pas été

abordées précédemment lors des entretiens avec les utilisateurs ou avec la

direction. Si vous déterminez que de telles données existent, vous devez en

tenir compte dans la structure de la base de données.

Prenez tous les rapports que vous avez rassemblés tout au long des processus

d'analyse et d'entretien et examinez-les une fois de plus avec les

participants. Demandez aux participants de réfléchir aux informations fournies

par les rapports et à la manière dont ils pourraient utiliser ces

informations. (Notez qu'ils devront faire des hypothèses sur la manière dont ils

pourraient utiliser les informations des nouveaux rapports.) Ensuite, demandez

aux participants de déterminer s'il existe des informations qui seraient utiles ou

précieuses pour l'organisation, mais qui ne sont pas reçues actuellement.

par quiconque au sein de l’organisation. S'ils déterminent qu'il existe

effectivement de nouvelles informations que l'organisation pourrait utiliser,

suivez le processus normal d'identification de ces informations ainsi que des

sujets et caractéristiques qui y sont représentés. Esquissez des échantillons de

nouveaux rapports pour obtenir des informations, le cas échéant, et ajoutez les

échantillons à votre collection existante de nouveaux rapports.

Par exemple, supposons que l'un des participants ait identifié un besoin

d'informations démographiques ; elle estime que cela aiderait l'organisation à

identifier un marché cible plus spécifique pour son produit. Aucun des rapports

existants ne fournit ces informations. Vous identifiez donc exactement ce dont

elle a besoin en travaillant avec elle pour créer une esquisse d'un rapport qui

présentera ces informations. (Elle peut en fait esquisser plus d'un rapport, mais

cela ne constitue ni un problème ni une source d'inquiétude.) Vous utilisez

ensuite les techniques appropriées pour identifier et noter les sujets et les

caractéristiques représentés dans le rapport et l'ajouter à votre collection

existante de nouveaux rapports. Plus tard dans le processus de conception,

vous définirez les structures de données nécessaires pour prendre en charge

les nouvelles informations.

Répétez cette procédure jusqu'à ce que les participants ne soient plus en

mesure d'identifier d'autres informations que l'organisation pourrait trouver

utiles ou précieuses. Une fois que vous êtes raisonnablement sûr d'avoir pris en

compte toutes les informations requises par l'organisation, suspendez le

processus d'entretien et commencez le processus de compilation de la liste de

terrain préliminaire.

Il est important que vous compreniez que vous devrez peut-être revoir ce

processus, même si vous et les participants pensez peut-être que vous avez

pris en compte toutes les informations que l'organisation pourrait

éventuellement utiliser. Vous identifierez généralement de nouvelles

informations au fur et à mesure du déroulement du processus de conception de

la base de données.
Compilation d'une liste complète de champs

La liste préliminaire des champs

Maintenant que vous avez terminé votre analyse de la base de données

actuelle et les entretiens avec les utilisateurs et la direction, vous pouvez créer

une liste de champs préliminaire . Cette liste représente les exigences

fondamentales en matière de données de l'organisation et constitue l'ensemble

principal de champs que vous définirez dans la base de données. Vous créez la

liste de champs préliminaire à l'aide d'un processus en deux étapes.

Étape 1 : Examiner et affiner la liste des caractéristiques

La première étape consiste à examiner et à affiner la liste de caractéristiques

que vous avez compilée tout au long du processus d'analyse et

d'entretien. Comme vous l'avez appris au chapitre 3 , un champ représente une

caractéristique d'un sujet particulier ; par conséquent, chaque élément de

votre liste de caractéristiques deviendra un champ. Toutefois, avant de

transformer ces caractéristiques en champs, vous devez d'abord examiner la

liste pour identifier et supprimer les caractéristiques en double.

Au cours des entretiens, vous avez identifié diverses caractéristiques dans les

réponses de chaque participant et les avez compilées dans une liste au fur et à

mesure de l'avancement de l'entretien. Il y a probablement eu des moments où

vous avez ajouté par erreur la même caractéristique à la liste plus d'une fois,

ou, sans le savoir, vous avez fait référence à la même caractéristique par deux

ou plusieurs noms différents. Par conséquent, votre liste de caractéristiques

nécessite quelques affinements.

Affiner les éléments portant le même nom

Commencez à affiner votre liste de caractéristiques en recherchant des

éléments portant le même nom. Lorsque vous trouvez une ou plusieurs

occurrences d’un nom particulier, déterminez si elles représentent toutes la

même caractéristique. Rayez de la liste toutes les occurrences du nom sauf

une si elles représentent la même caractéristique ; sinon, déterminez ce que

représente chaque instance du nom. Vous constaterez souvent qu'un nom en

double représente le même type de caractéristique que son homologue

d'origine, mais doit être associé à un sujet différent de celui de son

homologue. Dans ce cas, vous renommez le double pour refléter son lien avec

le sujet approprié.

Supposons, par exemple, que l'élément « Nom » apparaisse trois fois sur votre

liste de caractéristiques. Votre première tendance sera probablement de rayer

deux des occurrences, car votre objectif actuel est d’éliminer les

caractéristiques en double. Cependant, vous devez déterminer si chaque

instance de « Nom » représente une caractéristique distincte avant de la

supprimer. Vous pouvez facilement prendre cette décision en examinant vos

notes d’entretien ; cela vous aidera à vous rappeler quand et pourquoi vous

avez ajouté l'élément à la liste.

Après un examen attentif, vous découvrez que la première occurrence de «

Nom » représente une caractéristique du sujet « Clients », la seconde, une

caractéristique du sujet « Employés » et la troisième, une caractéristique du

sujet « Contacts ». Vous résolvez cette duplication en renommant chaque

occurrence de « Nom » (en utilisant le sujet comme préfixe) pour refléter

sonvéritable signification. Vous disposerez désormais de trois nouvelles

caractéristiques appelées « Nom du client », « Nom de l'employé » et « Nom du

contact ».
Les éléments similaires à « Nom » apparaissent généralement sur une liste de

caractéristiques et vous devez les traiter de la même manière. Vous verrez

généralement une ou plusieurs occurrences d'éléments tels que « Adresse », «

Ville », « État », « Code postal », « Numéro de téléphone » et « Adresse e-mail

», et vous pouvez les désigner collectivement comme génériques . articles. Le

point ici est que vous devez renommer chaque instance d'un élément

générique pour refléter sa véritable relation avec un sujet particulier,

garantissant ainsi que vous disposez d'une liste de champs aussi précise que

possible.

Affiner des éléments représentant la même caractéristique

Recherchez maintenant les éléments qui représentent la même caractéristique

et rayez-les tous sauf un. L’idée ici est qu’une caractéristique donnée ne doit

apparaître qu’une seule fois dans la liste des caractéristiques. Par exemple,

supposons que « Numéro de produit », « Numéro de produit » et « Numéro de

produit » apparaissent sur votre liste de caractéristiques. Il est évident que ces

éléments représentent tous la même caractéristique et vous n’en avez besoin

que d’un seul sur votre liste. Choisissez celui qui transmet le sens voulu de

manière claire, complète et sans ambiguïté et rayez les éléments restants de la

liste des caractéristiques. (Dans ce cas, le meilleur choix est « Numéro de

produit » car il remplit les critères précédents.)

S'assurer que les articles représentent les caractéristiques

Enfin, assurez-vous que chaque élément de votre liste représente

une caractéristique. Il est facile de placer accidentellement dans la liste des

éléments qui représentent des sujets. Vous pouvez tester chaque élément en

vous posant des questions telles que celles-ci :

Ce mot peut-il être utilisé pour décrire quelque chose ?

Ce mot représente-t-il un composant, un détail ou un morceau de quelque

chose en particulier ?

Ce mot représente-t-il un ensemble de choses ?

Ce mot représente-t-il quelque chose qui peut être décomposé en morceaux

plus petits ?

Selon l'élément avec lequel vous travaillez, il est plus facile de répondre à

certaines questions que d'autres. Lorsque vous constatez qu'un élément

représente un sujet plutôt qu'une caractéristique, supprimez-le de la liste des

caractéristiques et ajoutez-le à la liste des sujets. Assurez-vous d'identifier les

caractéristiques du nouveau sujet et de les ajouter à la liste de caractéristiques

existante.

Par exemple, disons que « Objet » apparaît sur votre liste de caractéristiques et

que vous ne savez pas vraiment s'il représente une caractéristique ou un

sujet. Utilisez les questions précédentes pour vous aider à prendre une

décision.

« Article » peut-il être utilisé pour décrire quelque chose ?

« Article » représente-t-il un composant, un détail ou un morceau de quelque

chose en particulier ?

Vous pourriez faire valoir que « Article » aide à décrire une vente dans la

mesure où il identifie ce qu'un client a acheté. D'un autre côté, on pourrait

aussi dire que « Article » n'est pas une caractéristique car il ne représente pas

un aspect singulier d'une vente. La « Date de vente », par exemple, représente

une caractéristique singulière d'une vente. Laissant le dilemme entourant ces

questions sans solution, vous passez à la question suivante :

« Item » représente-t-il une collection de choses ?

Vous pouvez facilement répondre à cette question en regardant la forme

plurielle du mot, qui dans ce cas est « Articles ». Si les « Objets » peuvent être

appelés une collection, il s'agit d'un sujet. Il commence à devenir clair que

« Item » représente une sorte de collection, et vous pouvez prendre une

décision finale en vous posant la dernière question :

Les « éléments » représentent-ils quelque chose qui peut être décomposé en

morceaux plus petits ?

Vous pouvez répondre à cette question en déterminant si vous pouvez

identifier des caractéristiques pour les « Articles ». Si vous le pouvez, alors

« Éléments » représente définitivement un sujet, et vous devez le déplacer

vers la liste des sujets. Vous devez également identifier ses caractéristiques et

les ajouter à votre liste de caractéristiques.

Continuez cette procédure jusqu'à ce que vous ayez examiné et affiné la liste

complète des caractéristiques à votre satisfaction. Lorsque vous avez terminé,

vous disposez de votre première version de la liste de champs

préliminaire. Vous allez maintenant y ajouter de nouveaux éléments et l'affiner

davantage au cours de l'étape suivante.

Étape 2 : Déterminez s’il existe de nouvelles caractéristiques dans l’un de vos

échantillons

Cette étape implique un examen de tous les échantillons que vous avez

collectés tout au long du processus d’analyse. Votre objectif est de déterminer

si certaines caractéristiques des échantillons doivent être ajoutées à la liste de

terrain préliminaire.
Commencez cette étape en mettant en évidence toutes les caractéristiques

que vous trouvez sur chaque échantillon. Ensuite, examinez chaque

caractéristique et déterminez si elle figure déjà sur la liste de champs

préliminaire ; Rayez-le sur l'échantillon s'il est déjà sur la liste. Ensuite, étudiez

les caractéristiques restantes et déterminez si l’une d’entre elles a la même

signification qu’un champ existant ; si c'est le cas, rayez-le sur

l'échantillon. (Utilisez la même procédure que celle utilisée à la première étape

pour effectuer cette détermination.) Enfin, ajoutez toutes les caractéristiques

en surbrillance restant sur les échantillons à la liste de champs préliminaire.

Par exemple, supposons que vous travaillez avec l'exemple de collecte de

données présenté dans la figure 6.14 .

Figure 6.14 Un exemple d'échantillon de collecte de données.

Mettez en surbrillance chaque caractéristique que vous trouvez sur

l'échantillon, comme le montre la figure 6.15 .

Figure 6.15 Un échantillon avec des caractéristiques mises en évidence.

Vous trouverez probablement plusieurs occurrences de diverses

caractéristiques dans certains échantillons. Comme vous pouvez le voir, « Nom

» et « Numéro de téléphone ». apparaissent deux fois sur cet échantillon

particulier. Dans ce cas, vous pouvez rayer les doublons car ils ont la même

signification que les instances d'origine.

Pour continuer avec l'exemple, supposons que vous ayez examiné la liste de

champs préliminaire et constaté que chaque caractéristique de l'échantillon est

déjàsur la liste à l'exception de « Nom » et « Numéro de téléphone ». Rayez les

éléments existants de l’échantillon pour montrer que vous les avez pris en

compte. Avant d'ajouter « Nom » et « Numéro de téléphone ». Cependant,

assurez-vous que les noms de ces éléments décrivent correctement leur

relation avec le sujet représenté dans l'échantillon. Dans ce cas, les deux

éléments restants représentent les caractéristiques d’un groupe de personnes

appelé « Contacts ». Par conséquent, vous renommez ces caractéristiques, en

utilisant le sujet comme préfixe, en « Nom du contact » et « Numéro de

téléphone du contact », puis vous les ajoutez à la liste de champs

préliminaire. Répétez cette procédure pour chaque échantillon que vous avez

collecté jusqu'à ce que vous ayez parcouru tous les échantillons que vous avez

collectés. Lorsque vous avez terminé, vous disposez de la deuxième version de

la liste préliminaire des champs.

Une note latérale : listes de valeurs

Lorsque vous examinez les caractéristiques d'une base de données, d'une

feuille de calcul ou d'un exemple de page Web, enregistrez sur une feuille de

papier séparée le nom de chaque caractéristique qui intègre une liste de

valeurs (également appelée liste énumérée ). Cette liste spécifie la plage de

valeurs acceptable pour une caractéristique particulière et applique souvent

une règle métier donnée. (Vous découvrirez les règles commerciales

au chapitre 11 , « Règles commerciales ».) Par exemple, supposons que vous

travailliez pour une entreprise manufacturière qui fait appel à quatre

fournisseurs spécifiques pour livrer ses marchandises à des clients à travers le

pays. Vous pouvez utiliser une liste de valeurs pour garantir qu'un utilisateur

sélectionne l'un de ces quatre fournisseurs pour expédier une commande

particulière. La figure 6.16 illustre cet exemple (remarque Ship Via) et montre

également deux types courants de liste de valeurs.

Figure 6.16 Un écran de base de données avec deux listes de valeurs.

Lorsque vous enregistrez le nom d'une caractéristique qui intègre une liste de

valeurs, enregistrez également les valeurs dans la liste. Si la liste contient un

grand nombre de valeurs, rédigez une brève description du type de valeurs

dans la liste et (si possible) une valeur minimale et maximale ; sinon, notez

chacune des valeurs. La figure 6.17 montre un exemple de l'enregistrement

que vous créez.

Figure 6.17 Enregistrement des caractéristiques qui intègrent des listes de
valeurs .

Vous pouvez faire preuve de discernement quant aux caractéristiques que vous

choisissez d’enregistrer. Par exemple, vous n'avez pas besoin d'enregistrer des

caractéristiques qui acceptent des ensembles de valeurs simples ou évidentes,

telles que « oui/non », « vrai/faux » ou « actif/inactif ». Au lieu de cela, vous

devez enregistrer des caractéristiques qui acceptent des ensembles de valeurs

distincts et spécifiques.

Mettez cette ou ces feuilles de côté une fois que vous avez fini d'enregistrer les

caractéristiques appropriées. Vous ferez référence à cette feuille lorsque vous

définirez les spécifications des champs de la base de données et à nouveau

lorsque vous définirez des règles métier.

La liste des champs calculés

Il y a un dernier raffinement que vous devez apporter à la liste de champs

préliminaire avant de pouvoir la considérer comme terminée : vous devez

supprimer chaque champ calculé et le placer sur une liste distincte. Cette

nouvelle liste devient votre liste de champs calculés. Rappelez-vous

du chapitre 3 qu'un champ calculé est un champ qui stocke le résultat d'une

concaténation de chaînes ou d'une expression mathématique comme

valeur. Vous répertoriez les champs calculés séparément, car vous les utiliserez

d'une manière spécifique ultérieurement dans le processus de conception.

Vous créez la liste des champs calculés à l'aide des champs existants de la liste

des champs préliminaires. Examinez la liste et déterminez s'il existe des

champs qui correspondent à la description d'un champ calculé. Les champs

dont les noms contiennent des mots tels que montant, total, somme, moyenne,

minimum, maximum et nombre sont probablement des candidats pour la liste

des champs calculés. Les noms courants pour les champs calculés incluent «

Sous-total », « Âge moyen », « Montant de la remise » et « Nombre de clients

». Au fur et à mesure que vous identifiez chaque champ calculé, supprimez-le

de la liste des champs préliminaires et placez-le dans la liste des champs

calculés. Lorsque vous aurez terminé votre examen de tous les champs de la

liste de champs préliminaire, vous disposerez de deux listes complètement

nouvelles : une troisième version de la liste de champs préliminaire et une liste

de champs calculés.
Examen des deux listes avec les utilisateurs et la direction

Mener de brefs entretiens avec les utilisateurs et la direction pour examiner les

éléments qui apparaissent sur la liste de champs préliminaire et le calcul.Liste

de champ. Votre objectif ici est de déterminer si des champs ont été omis de

l’une ou l’autre liste. Vous pouvez passer à l'étape suivante du processus de

conception lorsque tout le monde est convaincu que les listes sont

complètes ; sinon, identifiez les champs manquants et ajoutez-les à la liste

appropriée. Une fois les entretiens terminés, vous disposerez d'une version «

finale » de chaque liste.

Assurez-vous de mener ces entretiens car les commentaires des participants

vous fournissent un moyen de vérifier les champs des deux listes. Permettez-

moi de vous rappeler encore une fois d'éviter de trop vous investir dans l'idée

que ces listes sont absolument complètes et définitives. À ce stade, vous

n'avez peut-être pas encore identifié tous les champs qui doivent être inclus

dans la base de données (par inadvertance ; vous êtes presque sûr de

manquer quelques champs), mais si vous vous efforcez de rendre vos listes

aussi complètes que possible, l'inévitable les ajouts ou suppressions seront

rapides et faciles à effectuer.

EXEMPLE : ANALYSE D'UNE BASE DE DONNÉES

Travaillons à nouveau avec Mike et sa nouvelle base de données. Vous avez

déjà défini l'énoncé de mission et les objectifs de mission de la nouvelle base

de données de Mike. Il est maintenant temps d'effectuer une analyse, de

mener des entretiens et de dresser une liste préliminaire de terrain.

Tout d’abord, analysez la base de données actuelle de Mike. Vous constatez

qu'il conserve la plupart de ses données sur papier ; la seule exception est

l'inventaire de produits qu'il gère dans un tableur. Rassemblez des échantillons

des différents papiers que Mike utilise pour collecter des données et une

capture d'écran ou une impression de la feuille de calcul qu'il utilise pour gérer

l'inventaire des produits. Rassemblez ces échantillons dans un dossier pour une

utilisation ultérieure. Par exemple, la figure 6.18 montre un échantillon des

listes que Mike utilise pour collecter des informations sur les clients, ainsi

qu'une capture d'écran de son tableur.

Figure 6.18 Un échantillon sur papier et un échantillon généré par ordinateur

de Mike's Bikes.
Ensuite, identifiez les méthodes utilisées par Mike pour présenter

l’information. Lui et son équipe produisent actuellement une variété de

rapports qui présentent les informations dont ils ont besoin pour mener leurs

affaires quotidiennes. Ils génèrent la plupart des rapports à l'aide d'un

programme de traitement de texte. Rassemblez des échantillons de tous les

rapports et placez-les dans un dossier pour une utilisation ultérieure. La figure

6.19 montre un exemple de rapport que Mike crée sur son ordinateur.

Figure 6.19 Un exemple de rapport de Mike's Bikes.

Vous êtes maintenant prêt à interviewer le personnel de Mike. Voici quelques

points à retenir lorsque vous menez les entretiens.

• Identifiez les types de données que les membres du personnel utilisent et

comment ils utilisent ces données. Assurez-vous d'utiliser la technique

d'identification du sujet et la technique d'identification des caractéristiques

pour vous aider à analyser les réponses et à formuler des questions de suivi.

• Passez en revue tous les échantillons que vous avez collectés au début du

processus d’analyse. Déterminez comment chaque échantillon est utilisé,

rédigez une description appropriée et joignez la description à l’échantillon.

• Identifiez les besoins d’information du personnel. Déterminez les

informations qu'ils utilisent actuellement, les informations supplémentaires

dont ils ont besoin (n'oubliez pas d'utiliser les exemples) et le type

d'informations dont ils pensent avoir besoin à mesure que l'entreprise

évolue.

Lors de l'entretien, une des salariées se demande si elle peut ajouter un

nouveau champ au rapport de liste téléphonique des fournisseurs. Comment

répondez-vous ? Vous lui remettez le rapport et lui demandez de joindre une

note indiquant le nom du nouveau champ et une brève explication des raisons

pour lesquelles elle estime que cela est nécessaire. Lorsqu'elle a terminé,

remettez l'échantillon dans le dossier des échantillons de rapport. La figure

6.20 montre l'exemple de rapport avec la note jointe.

Figure 6.20 Un exemple de rapport avec une note jointe suggérant un

nouveau champ.

Vous mènerez l'entretien final avec Mike. Gardez les points suivants à l’esprit

lorsque vous parlez avec lui.

• Identifier les rapports qu'il reçoit actuellement ; vous devez savoir quel type

d'informations il utilise pour prendre des décisions commerciales. S'il reçoit

des rapports qui ne sont pas représentés dans votre groupe d'échantillons

de rapports, obtenez un échantillon de chaque rapport et ajoutez-le au

groupe, en mettant à jour les listes de sujets et de caractéristiques si

nécessaire.

• Examinez avec lui le groupe d'échantillons de rapports et déterminez s'il

peut identifier les sujets ou les caractéristiques que son personnel a

négligés . Utilisez les techniques appropriées pour identifier ces éléments,

puis ajoutez-les à la liste appropriée.

• Déterminez s'il existe des informations supplémentaires dont Mike a besoin

pour compléter les informations qu'il reçoit actuellement.

• Déterminez les types d’informations dont Mike aura besoin à mesure que

l’entreprise évolue.

Alors que vous et Mike discutez de ses futurs besoins en informations, il indique

qu'il aimerait recevoir de nouvelles informations une fois que l'entreprise aura

réellement démarré : il aimerait connaître les ventes totales de vélos par

fabricant. Il pense que ces informations l'aideraient à déterminer quels vélos il

devrait constamment garder en stock. Un tel rapport n'existe pas actuellement,

alors demandez à Mike de l'esquisser sur une feuille de papier. Ensuite,

identifiez les sujets et les caractéristiques représentés dans le rapport et

ajoutez-les à la liste appropriée. Ajoutez le nouveau rapport à votre groupe

d’exemples de rapport. La figure 6.21 montre le croquis du nouveau rapport de

Mike.
Figure 6.21 Le croquis du nouveau rapport de Mike.

Votre analyse est maintenant terminée. Vous avez interviewé Mike et son

équipe, vous avez rassemblé tous les échantillons pertinents et vous avez créé

une liste de sujets et une liste de caractéristiques. Une liste partielle des sujets

et des caractéristiques est présentée dans la figure 6.22 . Tout ce que vous

avez à faire maintenant est de créer votre liste de champs préliminaire.

Figure 6.22 Listes partielles de sujets et de caractéristiques pour les vélos de

Mike.
Comme vous le savez déjà, vous devez affiner la liste des caractéristiques

avant qu'elle puisse devenir la première version de la liste préliminaire des

champs. Rayez les caractéristiques en double, les éléments qui représentent

la même caractéristique, et affinez les éléments qui portent des noms

génériques. (Vous vous souvenez du problème avec la caractéristique appelée

« Nom » ? Si vous trouvez de telles caractéristiques, le moment est venu de les

résoudre.) Ensuite, examinez tous vos échantillons et déterminez s'ils

contiennent des caractéristiques qui n'apparaissent pas actuellement dans la

liste de champs préliminaire. Ajoutez à la liste toutes les nouvelles

caractéristiques que vous trouvez. Lorsque vous avez terminé ces tâches, vous

disposez de la première version de votre liste de champs préliminaire.

Maintenant, vous rayez tous les champs calculés de la liste préliminaire des

champs et les placez sur leur propre liste ; cela devient votre nouvelle liste de

champs calculés. La figure 6.23 montre une petite partie de votre liste de

champs préliminaire et de votre liste de champs calculée finale.

Figure 6.23 Une liste de champs préliminaire partielle et une liste de champs
calculés.

Note

Vous avez peut-être remarqué que chaque liste inclut une date dans le

titre. Datar vos listes est une bonne idée afin que vous puissiez conserver un

historique clair de leur évolution.

Résumé

Ce chapitre a commencé par expliquer pourquoi vous devriez analyser la base

de données actuelle de l'organisation. Vous avez appris que l'analyse vous aide

à identifier les aspects de la base de données actuelle qui vous seront utiles

lors de la conception de la nouvelle base de données. Armé de ces

informations, vous pouvez concevoir une base de données qui répond le mieux

aux besoins de l'organisation. Ensuite, nous avons brièvement examiné les

deux types de bases de données couramment utilisées par les organisations :

les bases de données papier et les bases de données existantes . Nous avons

terminé celadiscussion en identifiant les trois étapes utilisées dans

le processus d'analyse : examiner la manière dont les données sont collectées,

examiner la manière dont l'information est présentée et mener des entretiens

avec le personnel de l'organisation.

Le chapitre se poursuit par une discussion du processus de révision. Vous avez

appris à examiner la manière dont l'organisation collecte ses données et à

rassembler un ensemble d' échantillons de collecte de données . Vous avez

ensuite appris à examiner la manière dont l'organisation présente les

informations et à rassembler un ensemble d' échantillons de rapports .

Nous avons ensuite discuté du processus que vous utilisez pour mener des

entretiens et vous avez appris pourquoi les entretiens sont utiles à cette étape
du processus de conception. Au cours de cette discussion, vous avez appris

deux techniques essentielles au succès des entretiens : la technique

d'identification du sujet et la technique d'identification des caractéristiques.

La réalisation d’entretiens avec les utilisateurs a été le prochain sujet de

discussion. Nous avons examiné les quatre questions que vous devez aborder

lors de ces entretiens, ainsi que les techniques que vous utilisez pour les

résoudre. Ensuite, nous avons discuté de la conduite d’entretiens avec la

direction. Ici, vous avez découvert les problèmes et les techniques que ces
entretiens intègrent.

Enfin, nous avons discuté du processus de compilation d'une liste de

champs basée sur la liste de caractéristiques et les caractéristiques qui

apparaissent dans les échantillons. Vous avez appris que vous décomposez la

liste de champs en deux listes distinctes : une liste de champs préliminaire et

une liste de champs calculés. La liste préliminaire des champs énumère les

exigences fondamentales en matière de données de l'organisation et établit

l'ensemble principal des champs que vous devez définir dans la base de

données. La liste des champs calculés se compose de champs contenant des

valeurs résultant de concaténations de chaînes ou d'expressions

mathématiques. Vous avez également appris à compiler une liste de valeurs,

c'est-à-dire une liste qui spécifie la plage de valeurs acceptable pour un champ

particulier dans la liste de champs préliminaire et qui aide souvent à appliquer

une règle métier donnée.

Questions de révision

1. Énoncez deux objectifs de l’analyse de la base de données actuelle.

2. Vrai ou Faux : Vous pouvez adopter la structure actuelle de la base de

données comme base pour la nouvelle structure.

3. Qu'est-ce qu'une base de données existante ?

4. Énoncez deux étapes du processus d’analyse.

5. Quels types de logiciels informatiques devriez-vous examiner lors de

l’analyse ?

6. Pourquoi devriez-vous mener des entretiens après avoir collecté des

échantillons de collecte de données et de présentation d’informations ?

7. Comment utilisez-vous les questions « ouvertes » et « fermées » ?

8. Qu'est-ce que la technique d'identification du sujet ?

9. Comment identifiez-vous les attributs spécifiques d’un sujet particulier ?

10. Vrai ou faux : vous devez interroger les utilisateurs et la direction en même

temps.

11. Quels sont les trois types fondamentaux d’exigences en matière

d’information que vous devez identifier ?

12. Qu'est-ce que la liste préliminaire des champs ?

13. Indiquez pourquoi chaque élément de la liste préliminaire des champs doit

avoir un nom unique.

14. Qu'est-ce qu'une liste de valeurs ?

15. Que sont les champs calculés ? Que devriez-vous faire (le cas échéant) à

leur sujet ?

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
6. Analyse de la base de données actuelle
7. Établir des structures de table
8. Clés
8h 33min restantes

Établir des structures de table

C'est une erreur capitale de théoriser avant de disposer de données.

—S HERLOCK H OLMES ,

LES AVENTURES DE S HERLOCK H OLMES _

Sujets abordés dans ce chapitre

Définir la liste des tables préliminaires

Définir la liste de la table finale

Association de champs à chaque table

Affiner les champs

Affiner les structures des tables

Exemple : établissement de structures de table

Résumé

Questions de révision

Les organisations utilisent des bases de données pour suivre divers sujets qui

leur tiennent à cœur. Par exemple, une clinique médicale garde une trace,

entre autres, de ses patients, de ses médecins et de ses rendez-vous ; une

entreprise de location d'équipement doit conserver des données sur ses

clients, ses équipements et ses contrats de location ; et un bureau du

registraire s'occupe (au minimum) des étudiants, du personnel enseignant et

des cours. Dans tous les cas – et dans tout autre scénario que vous pouvez

imaginer – un tableau dans la base de données représente chaque sujet. De

plus, chaque tableau est composé de champs qui représentent les

caractéristiques qui définissent ou décrivent le sujet du tableau. Les tableaux

constituent la base même de la base de données et garantissent une base

solide et solide lorsqu'ils sont correctement conçus.

Définir la liste des tables préliminaires

Au cours de cette partie du processus de conception de la base de données,

vous définirez une liste de tables préliminaire que vous utiliserez pour identifier

et établir les tables de la nouvelle base de données. Vous utiliserez trois

procédures pour développer cette liste. La première implique d'utiliser la liste

de terrain préliminaire, la seconde implique d'utiliser la liste de sujets que vous

avez rassemblés au cours du processus d'entretien et la troisième implique

d'utiliser les objectifs de mission que vous avez définis au début du processus

de conception de la base de données. Vous passerez ensuite à la construction

de la structure de chaque table à l'aide des champs de la liste de champs

préliminaire.

Identifier les sujets implicites

Le processus de définition des tables pour la base de données commence par

un examen de la liste de champs préliminaire. Votre objectif est d'identifier les

sujets impliqués par les champs de la liste.

Vous vous demandez peut-être pourquoi vous examinez la liste préliminaire des

champs au lieu de commencer par la liste des sujets. La liste des sujets semble

être un point de départ plus intuitif. Après tout, vous avez soigneusement

construit cette liste au cours du processus d'entretien et vous avez été

influencé par les conversations que vous avez eues avec les utilisateurs et la

direction. Tout cela vous a sûrement aidé à identifier chaque sujet qui doit être

représenté dans la base de données. Vous avez peut-être raison, mais vous

pourriez avoir un problème mineur si vous vous trompez : des tables

manquantes.
L'étude des champs de la liste de champs principale vous aide à identifier les

sujets d'un point de vue impartial : vous laissez les champs vous « parler ». Il

est crucial que vous regardiez maintenant cette liste le plus objectivement

possible, comme si vous ne l'aviez jamais vue auparavant, sans aucun des

préjugés que vous avez assimilés au cours du processus d'entretien. Cela

permet de voir comment certains groupes de domaines suggèrent des sujets

spécifiques, dont certains n'ont peut-être pas été identifiés lors du processus

d'entretien. Vous pouvez aussiutilisez la liste de champs préliminaire pour

vérifier de nombreux sujets figurant sur la liste de sujets. Utiliser la liste de

champs préliminaire de cette manière vous permet de recouper vos travaux

antérieurs et vous aide à vous assurer que la nouvelle structure de la base de

données inclut tous les sujets nécessaires.

Lorsque vous examinez la liste préliminaire des champs, demandez-vous si un

certain ensemble de champs définit ou décrit un sujet particulier. Passez à un

autre ensemble de champs si rien ne vous vient à l’esprit. Lorsque vous pouvez

déduire un sujet à partir du champ de la liste, entrez ce sujet dans une

nouvelle liste de tableaux préliminaires. La figure 7.1 montre un échantillon

partiel d'une liste de champs préliminaire et illustre comment un ensemble de

champs peut suggérer un sujet.

Figure 7.1 Utilisation de la liste de champs préliminaire pour identifier les
sujets.

Continuez votre examen jusqu'à ce que vous ayez scanné tous les champs et

identifié autant de sujets que possible. Assurez-vous d'ajouter chaque sujet que

vous identifiez à la liste des tableaux préliminaires. Cette liste s'allongera au

fur et à mesure que vous travaillerez avec la liste des sujets et des objectifs de

mission. La figure 7.2 montre un exemple de la première version d'une liste de

tableaux préliminaires.
Figure 7.2 La première version de la liste des tableaux préliminaires.

Utiliser la liste des sujets

Créez maintenant une deuxième version de la liste des tableaux préliminaires

en fusionnant la liste des sujets (créée lors des entretiens avec les utilisateurs

et la direction) avec la première version de la liste des tableaux préliminaires

(compilée en étudiant la liste des champs préliminaires). Cette nouvelle version

contient une liste de tableaux plus complète. La fusion des deux listes est un

processus en trois étapes, qui consiste à résoudre les éléments en double, à

résoudre les éléments qui représentent le même sujet et à combiner les

éléments restants en une seule liste.

Étape 1 : Résoudre les éléments en double

Commencez cette étape en examinant et en recoupant chaque élément de la

liste de sujets par rapport aux éléments de la liste du tableau

préliminaire. Votre objectif ici est d'identifier les éléments en double, qui sont

des éléments de la liste des sujets qui apparaissent déjà sur la liste du tableau

préliminaire. Vous devez faire très attention à la manière dont vous résolvez les

éléments en double que vous trouvez. Commencez par déterminer si les

éléments représentent des sujets différents , malgré le fait qu'ils portent le

même nom. (Utilisez vos notes d'entretien si nécessaire pour vous aider à

prendre votre décision.) Si elles représentent des sujets différents, renommez

chaque élément afin qu'il identifie avec précision le sujet qu'il représente, puis

ajoutez les deux éléments à la liste du tableau préliminaire ; sinon, déterminez

s’ils représentent vraiment la même chosesujet. Lorsque vous concluez que les

deux éléments représentent le même sujet, rayez l’élément de la liste des

sujets et conservez celui qui apparaît sur la liste du tableau

préliminaire. Reprenez l'examen jusqu'à ce que vous ayez examiné tous les

éléments de la liste des sujets et de la liste du tableau préliminaire. Jetons un

coup d'œil à un exemple de ce processus.

Supposons que vous développez une base de données pour une entreprise de

location d'équipement et que vous travaillez avec la liste de sujets et la liste

des tableaux préliminaires présentés dans la figure 7.3 .

Figure 7.3 La liste des sujets et la liste des tableaux préliminaires pour une
entreprise de location d'équipement.

En examinant ces listes, vous découvrez deux éléments en double :

« Équipement » et « Contrats de location ». Ces éléments méritent un examen

plus approfondi, vous commencez donc par « Équipement » et essayez de

déterminer si chaque occurrence représente un sujet différent . En examinant

vos notes d'entretien, vous constatez que « Équipement » sur la liste des sujets

représente des éléments tels que des outils, des appareils électroménagers et

du matériel audiovisuel. Vous vous souvenez alors que « Équipement » sur la

liste du tableau préliminaire comprend également les camions, les

fourgonnettes et les remorques. Vous examinez plus en détail vos notes

d'entretien et découvrez que la location de véhicules est traitée différemment

de la location d'équipement « normale ». Par conséquent, chaque occurrence

de « Équipement » représente un sujet différent. Vous résolvez la duplication

en conservant une occurrence de « Équipement » et en renommant les autres

« Véhicules ». Vous répertoriez ensuite les deux éléments dans la liste des

tableaux préliminaires.
Vous suivez maintenant le même processus avec les « Contrats de

location ». Heureusement, vous découvrez que les deux occurrences partagent

exactement la même signification. La seule chose que vous devez faire dans ce

cas est de rayer « Contrats de location » dans la liste des sujets. Vous pouvez

maintenant poursuivre votre examen jusqu'à ce que vous ayez inspecté

chaque élément de la liste des sujets. La figure 7.4 montre la liste révisée des

sujets et la liste des tableaux préliminaires.

Figure 7.4 Liste révisée des sujets et liste préliminaire révisée des tableaux
(première vue).

Étape 2 : résoudre les éléments qui représentent le même sujet

Votre objectif au cours de cette étape du processus de fusion est de déterminer

si un élément de la liste des sujets et un élément de la liste du tableau

préliminaire représentent le même sujet même s'ils portent des

noms différents . Lorsque vous identifiez un tel ensemble d'éléments,

sélectionnez le nom qui représente le mieux le sujet et utilisez-le comme

identifiant unique pour ce sujet, puis traitez le nom de cette manière :

• Si le nom que vous avez sélectionné apparaît déjà dans la liste du tableau

préliminaire, rayez son homologue dans la liste des sujets.

• Si le nom apparaît sur la liste des sujets, supprimez son homologue de la

liste du tableau préliminaire et remplacez -le par le nom de la liste des

sujets.

Répétez ce processus jusqu'à ce que vous ayez couvert tous les éléments de la

liste des sujets.

En poursuivant avec l'exemple de l'entreprise de location d'équipement,

supposons que vous ayez découvert que les « Clients » et les « Employés » sur

la liste des sujets et les « Clients » et les « Représentants commerciaux » sur la

liste du tableau préliminaire représentent (respectivement) le même sujet

(voir Figure 7.4 ). Décidant de traiter d'abord des « Clients » et des « Clients »,

vous examinez vos notes d'entretien et déterminez que « Clients » est le nom

qui représente le mieux à la fois les personnes et les organisations qui louent

du matériel auprès de l'entreprise. Vous résolvez ensuite la duplication en

conservant « Clients » et en rayant « Clients ». Passant à l'ensemble suivant

d'éléments en double, vous décidez de conserver « Employés » et de

supprimer « Représentants commerciaux », car vous pensez que « Employés »

décrit le mieux les personnes employées par l'entreprise, quel que soit leur

poste. La figure 7.5 montre une version révisée des deux listes et la résolution

des éléments en double.

Figure 7.5 Liste révisée des sujets et liste préliminaire révisée des tableaux
(deuxième vue).

Étape 3 : Combinez les éléments de la liste des sujets et de la liste de champs

préliminaire

La dernière étape de ce processus est la plus simple des trois. Tout ce que vous

avez à faire est d'ajouter les éléments restants de la liste des sujets à la liste

du tableau préliminaire. Jetez la liste des sujets, vous n’en aurez plus besoin. La

liste qui reste devient la deuxième version de la liste des tableaux

préliminaires. C'est tout ce qu'on peut en dire! La figure 7.6 montre la

deuxième version de la liste des tableaux préliminaires, qui est le résultat de la

fusion des deux listes présentées dans la figure 7.5 .

Figure 7.6 La deuxième version de la liste des tableaux préliminaires.

Utiliser les objectifs de la mission

Dans cette troisième et dernière procédure, vous utilisez les objectifs de la

mission pour déterminer si vous avez oublié des sujets lors des deux

procédures précédentes. C'est votre dernière opportunité d'ajouter des tables à

la liste préliminaire des tables.

Commencez par le premier objectif de la mission et utilisez la technique

d'identification du sujet pour identifier les sujets représentés dans cette

déclaration. Notez chaque sujet que vous identifiez sur une feuille de papier

séparée, puis vérifiez-le par rapport aux éléments de la liste du tableau

préliminaire. Utilisez ici les mêmes techniques que celles utilisées dans la

procédure précédente.
1. Lorsqu'un élément que vous avez noté dans l'énoncé de l'objectif de la

mission correspond à un élément de la liste du tableau préliminaire,

déterminez si les éléments représentent des sujets différents. Si tel est le

cas, attribuez un nom approprié à chaque occurrence, puis ajoutez-les à la

liste des tableaux préliminaires ; sinon, rayez l’élément en double que vous

avez noté.

2. Lorsqu'un élément que vous avez noté dans l'énoncé de l'objectif de la

mission a un nom qui est synonyme du nom d'un élément de la liste du

tableau préliminaire et que les deux éléments représentent le même sujet,

sélectionnez le nom qui identifie le mieux ce sujet et utilisez-le dans la liste

préliminaire. Liste des tableaux.

3. Lorsqu'un élément que vous avez noté dans l'énoncé de l'objectif de la

mission représente un nouveau sujet, ajoutez-le à la liste du tableau

préliminaire.

Répétez ces étapes jusqu'à ce que vous ayez atteint tous les objectifs de la

mission. Voici un exemple de la façon dont vous utilisez ces techniques pour

revoir les objectifs de la mission.

Supposons que vous concevez une base de données pour une école de

formation au pilotage. Vous venez tout juste de commencer ce processus

particulier et vous venez d'utiliser la technique d'identification du sujet sur

l'énoncé suivant :

Nous devons conserver des données sur nos pilotes et leurs certifications .

Vous vérifiez maintenant les sujets que vous avez identifiés dans cet objectif de

mission avec les éléments de la liste du tableau préliminaire présentée dans la

figure 7.7 .
Figure 7.7 Liste préliminaire des tableaux pour une école de formation au
pilotage.

Dans ce cas, vous rayez « pilotes » dans l'énoncé de l'objectif de la mission, car

il existe déjà dans la liste du tableau préliminaire et représente le même

sujet. Vous décidez alors d’examiner plus à fond les « certifications » et, après

mûre réflexion, vous faites ces observations.

• Il n'apparaît pas sur la liste des tableaux préliminaires.

• Il ne duplique aucun élément de la liste des tables préliminaires.

• Son nom n'est synonyme d'aucun élément de la liste préliminaire du

tableau.

• Il ne représente pas le même sujet que n’importe quel autre élément de la

liste du tableau préliminaire.

Ces résultats indiquent que le terme « certifications » est un nouvel élément et

devrait être ajouté à la liste du tableau préliminaire. Donc, vous l'ajoutez à la

liste du tableau préliminaire et vous le rayez sur l'énoncé des objectifs de la

mission ; cela vous montre que vous avez déjà traité cet élément particulier. La

figure 7.8 montre la version révisée de la liste des tableaux préliminaires.

Figure 7.8 Liste des tableaux préliminaires révisée.

Définir la liste de la table finale

Votre liste de tables préliminaires est aussi complète que possible à ce stade,

vous allez donc maintenant la transformer en liste de tables finale . Cette

nouvelle liste intègre deux éléments qui ne figurent pas actuellement dans la

liste préliminaire des tables : le type de table et la description de la table. La

figure 7.9 montre un exemple de liste de table finale.

Figure 7.9 Un exemple de liste de table finale.

Un type de table vous permet de classer une table en fonction du rôle qu'elle

joue dans la base de données et vous fournit un moyen d'identifier les tables

qui fonctionnent de manière similaire. Le rôle de la table détermine son type, et

vous pouvez associer quatre types de table à une table donnée :

1. Une table de données représente un sujet important pour l'organisation et

constitue le fondement principal des informations fournies par la base de

données. (Vous en apprendrez davantage sur les tableaux de données plus

loin dans ce chapitre.)

2. Une table de liaison établit un lien entre deux tables dans une relation

plusieurs-à-plusieurs. ( Le chapitre 10 , « Relations entre les tables », traite

plus en détail de la liaison des tables.)

3. Une table de sous-ensemble contient des champs liés à une table de

données particulière et décrit en outre le sujet de la table de données d'une

manière très spécifique. (Vous en apprendrez davantage sur les tables de

sous-ensembles plus loin dans ce chapitre.)

4. Une table de validation contient des données relativement statiques et

constitue un élément crucial de l'intégrité des données. ( Le chapitre 11 ,

« Règles métier », fournit plus de détails sur ce type de tableau.)

Une description de tableau fournit une définition claire du sujet représenté par

le tableau et indique pourquoi le sujet est important pour

l'organisation. Certaines directives régissent la façon dont vous créez une

description de table et vous en apprendrez davantage plus loin dans ce

chapitre. Vous avez une dernière tâche à effectuer avant de transformer votre

liste de tables préliminaire en liste de tables finale : affiner les noms des tables.

Affiner les noms des tables

Nommer une table est une affaire plus complexe que vous ne le pensez pour le

moment. Comme vous l'avez appris au chapitre 3 , « Terminologie », un tableau

représente un seul sujet ; son nom doit donc clairement identifier le sujet qu'il

représente.

Directives pour la création de noms de table

Les instructions suivantes vous aideront à créer des noms de table clairs, sans

ambiguïté, descriptifs et significatifs. Ils vous aideront également à garantir

que vous nommez vos tables de manière cohérente.

• Créez un nom unique et descriptif qui ait du sens pour l'ensemble de

l'organisation. L'utilisation de noms uniques permet de garantir que chaque

tableau représente clairement un sujet différent et que tous les membres de

l'organisation comprendront ce que le tableau représente. (Si vous

rencontrez des noms de table en double à ce stade, résolvez le problème en

utilisant les techniques que vous avez apprises plus tôt dans ce chapitre.)

Choisissez des noms suffisamment descriptifs pour être explicites. «

Entretien du véhicule » est un exemple de bon nom descriptif. Définir un

nom unique et descriptif demande un certain travail de votre part, mais cela

en vaut la peine à long terme.

• Créez un nom qui identifie avec précision, clarté et sans ambiguïté le sujet

du tableau. Des noms vagues ou ambigus indiquent généralement que le

tableau représente plus d'un sujet. Lorsque vous rencontrez un tel nom,

identifiez les sujets que le tableau représente réellement, puis traitez

chaque sujet comme un tableau distinct. « Dates » est un bon exemple de

nom de table vague. On ne sait vraiment pas ce que représente le tableau

sans se référer à sa description. Par exemple, supposons que vous concevez

une base de données pour une agence de divertissement et que ce tableau

apparaisse dans la liste des tableaux préliminaires. En voyant ce nom de

table, vous décidez de revoir vos notes d’entretien. Vous découvrez qu'une

personne dit que « Dates » représente des rendez-vous pour des réunions

avec des clients, et une autre personne dit que cela représente des dates de

réservation pour l'écurie d'artistes de l'agence. Ce tableau représente

clairement deux sujets, vous supprimez donc « Dates » de la liste des

tableaux préliminaires et le remplacez par deux nouveaux tableaux appelés

« Réunions clients » et « Horaires des artistes ».

 Le nom le plus vague et le plus ambigu que vous puissiez attribuer à une

table est peut-être « Divers ». Il n’identifie aucun sujet. Vous pourriez

parfois vous sentir obligé de créer un tableau « Divers » parce que vous ne

savez tout simplement pas quoi faire avec certains champs de votre liste de

champs préliminaire. Lorsque cela se produit, arrêtez-vous, faites une

pause, puis revenez et réexaminez ces champs. Appliquez soigneusement et

méthodiquement les techniques de conception que vous avez apprises, et

vous êtes sûr de déterminer quoi faire avec les champs après tout.

• Utilisez le nombre minimum de mots nécessaire pour transmettre le sujet du

tableau. Tout le monde dans l’organisation doit être capable d’identifier ce

que représente le tableau sans avoir à lire sa description. Même si votre

objectif est de créer un nom de table court et succinct, évitez d'utiliser une

approche minimaliste. « TD_1 » est un bon exemple de nom extrêmement

court. Vous n'aurez pas la moindre idée de ce que représente ce tableau à

moins de connaître lesignification de chaque caractère du nom. Vous devez

également éviter d’aller dans la direction opposée. « Équipement d'entretien

de véhicules polyvalents » est beaucoup trop long et peut facilement être

raccourci en « équipement ».
• N'utilisez pas de mots qui véhiculent des caractéristiques physiques. Évitez

d'utiliser des mots tels que fichier, enregistrement et table dans le nom de

la table, car ils ajoutent un niveau de confusion dont vous n'avez pas

besoin. Un nom de table incluant ce type de mot est très susceptible de

représenter plusieurs sujets. Considérez le nom « Dossier patient ». À

première vue, ce nom peut sembler acceptable. Vous vous rendrez compte,

cependant, que ce nom pose des problèmes potentiels lorsque vous prenez

le temps de réfléchir à ce qu'un « dossier patient » est censé représenter. Le

nom contient un mot que vous vous efforcez d'éviter ( record ) et il

représente potentiellement trois sujets : « patients », « médecins » et «

examens ». Dans cette optique, supprimez « patients » de la liste des

tableaux préliminaires et remplacez-la par trois nouveaux tableaux, un pour

chacun des trois sujets.

• N'utilisez pas d'acronymes et d'abréviations. Les acronymes sont difficiles à

déchiffrer, les abréviations transmettent rarement le sujet du tableau et

toutes deux violent la première directive de cette liste. Prenez les

acronymes, par exemple. Supposons que vous aidiez une organisation à

réviser la structure de sa base de données et que vous rencontriez une table

nommée « SC ». Comment savoir ce que représente le tableau sans

connaître la signification des lettres elles-mêmes ? Le fait est qu’il n’est pas

facile d’identifier le sujet du tableau. De plus, vous constaterez peut-être

que le tableau signifie des choses différentes pour différents départements

de l'organisation. Vous décidez donc de mener un bref entretien avec

certains membres du personnel pour déterminer ce que représentent les

lettres. (Maintenant, c'est la partie effrayante.) À votre incrédulité, vous

découvrez que les membres du personnel pensent que cela signifie

« Comités directeurs » ; le personnel des systèmes d'information pense qu'il

s'agit de « Configurations système » ; et les personnes en sécurité insistent

sur le fait que cela représente des « codes de sécurité ». CeCet exemple

illustre clairement pourquoi vous devez faire tout votre possible pour éviter

d'utiliser des abréviations et des acronymes dans un nom de table.

• N'utilisez pas de noms propres ou d'autres mots qui restreindraient

indûment les données pouvant être saisies dans le tableau. Cette ligne
directrice vous évitera de tomber dans le piège de la création de structures

de tables en double. Un nom tel que « Employés de la région du Sud-

Ouest », par exemple, restreint considérablement les données que vous

pouvez saisir dans ce tableau. À mesure que l’organisation se développe,

comment allez-vous gérer les employés d’autres régions ? Lorsque

l'organisation commencera à embaucher des employés dans l'État de

Washington, l'Oregon et l'Idaho, vous devrez créer une table « Employés de

la région du Nord-Ouest du Pacifique », et vous devrez créer une table «

Employés de la région de l'Ouest » lorsque l'organisation commencera à

embaucher. des gens en Arizona, en Utah, au Nevada et en Californie.

 Les principes de conception de bases de données appropriés dictent que

vous ne devez pas créer de structures en double comme celles-ci, car elles

peuvent être très problématiques.

1. Les utilisateurs pourraient avoir du mal à récupérer simultanément les

données des trois tables.

2. La personne qui gère la base de données aurait la responsabilité

supplémentaire de garantir que les tables sont toujours structurellement

synchronisées. S'il ajoute, modifie ou supprime un champ dans une table,

il doit effectuer la même action sur toutes les autres tables.

3. La personne qui gère la base de données aurait également la

responsabilité supplémentaire d'assurer l'intégrité des données

synchronisées entre les tables. Il doit être en mesure de garantir que les

données sont transférées de manière complète et exacte d'une table à

l'autre lorsqu'un employé déménage d'une région à une autre.

• N'utilisez pas de nom qui identifie implicitement ou explicitement plus d'un

sujet. C'est l'une des erreurs les plus courantes que vous pouvezmake avec
un nom de table, et il est relativement facile à identifier. Ce type de nom

contient généralement le mot et ou ou et des caractères tels que la barre

oblique (\) ou l'esperluette (&) ; les exemples incluent « Département ou

succursale » et « Installation/Bâtiment ». Un tableau dont le nom est ambigu

suggère que vous n'avez peut-être pas identifié le sujet de manière claire ou

précise lors des processus d'analyse et d'entretien. Vous pouvez remédier à

ce problème en révisant vos notes et en effectuant des analyses et des

entretiens plus approfondis si nécessaire. N'oubliez pas que vous devez

toujours vous assurer que chaque tableau ne représente qu'un seul sujet.
 Un autre nom qui entre dans cette catégorie est « Divers ». (Oui, voici

encore ce nom !) Il y a un instant, je disais que ce nom n'identifiait pas du

tout un seul sujet ; c'est une affirmation correcte et valable. Il est également

vrai, cependant, que le nom identifie implicitement plus d’un sujet ; vous ne

pouvez pas identifier spécifiquement les sujets car le nom est vague et

ambigu. Le dictionnaire en ligne Merriam-Webster définit le mot lui-même

comme suit :

Divers adj. 1. composé de choses ou de membres divers ; hétérogène. 2.

avoir divers traits.

Vous pouvez clairement voir les problèmes que ce nom crée, vous ne devez

donc pas du tout l'utiliser comme nom de table. Il y a certainement de

bonnes raisons de ne pas le faire.

• Utilisez la forme plurielle du nom. Comme vous le savez, un tableau

représente un seul sujet, qui peut être un objet ou un événement. Vous

pouvez aller plus loin dans cette définition et affirmer qu'une table

représente une collection d' objets ou d'événements similaires . Par

exemple, un commercial souhaite conserver des données sur tous ses

clients, pas seulement sur un seul ; et une entreprise de location de voitures

souhaite garder une trace de tous ses véhicules, pas seulement de la BMW

bleue. Utiliser le pluriel du nom de la table est une bonne idée car cela

rendeffacez votre intention de faire référence à une collection. Bien

entendu, les collections prennent toujours le pluriel (« Bateaux » et non «

Bateau »). En revanche, les mots qui identifient les champs sont toujours au

singulier (« Téléphone personnel » et non « Téléphones résidentiels »). Le

respect de cette règle vous permettra de différencier facilement les noms

de tables et les noms de champs dans toute documentation que vous créez
pour la base de données. (Lorsque vous renommez vos tableaux, n'oubliez
pas que la forme plurielle de certains mots ne se termine pas par - s ou

- es. Par exemple, les formes singulière et plurielle de « équipement » sont

exactement les mêmes.)

Utilisez ces instructions pour affiner chaque nom de table dans la liste de

tables préliminaire. Lorsque vous avez terminé, cette liste devient votre liste de

table finale et le reste pendant toute la durée du processus de conception de la

base de données. Notez que la liste est « définitive » uniquement dans le sens

où vous avez pris en compte tous les tableaux que vous avez identifiés tout au

long du processus d'analyse. Il est très probable que vous ajoutiez de nouvelles

tables à cette liste en fonction des exigences imposées par les relations,

l'intégrité des données ou d'autres informations que vous développez.

Note

Les lignes directrices relatives à l'utilisation du pluriel pour un nom de table

sont particulièrement utiles lorsque vous travaillez sur la conception logique de

la base de données. Il est très facile de différencier les noms de tables des

noms de champs, en particulier lorsque vous les affichez sur un écran de

projection ou lorsque vous les avez tous écrits sur un tableau blanc dans une

salle de conférence.

Gardez toutefois à l’esprit que les noms des tables sont susceptibles de

changer une fois que vous (ou le développeur de base de données chargé de

l’implémentation de la base de données) commencerez à implémenter la base

de données dans une application SGBDR spécifique. Les noms devront ensuite

être conformes aux conventions de dénomination standard de votre

organisation ou que les développeurs utilisent couramment pour le SGBDR.

Indiquer les types de tables

Comme vous l'avez appris plus tôt dans ce chapitre, vous indiquez le type de

chaque table dans la liste des tables finales. Rappelez-vous que les quatre

classifications que vous pouvez utiliser pour identifier le type de table sont les

données, les liaisons, les sous-ensembles et la validation.

Lorsque vous créez pour la première fois votre liste de table finale, chaque

élément de la liste est une table de données car il représente un sujet

important pour l'organisation et sert de base principale aux informations

fournies par la base de données. Il n'y aura pas de tables de liaison ou de

tables de validation dans la liste car vous n'avez pas encore défini de relations

ni imposé l'intégrité des données. (Vous aborderez ces problèmes plus tard

dans le processus de conception.) La liste ne contiendra pas de tables de sous-

ensembles car vous les définissez après avoir attribué des champs aux tables
de données.

Pour le moment, désignez chaque table de la liste des tables finales comme

table de données. Vous attribuerez d’autres types de tables ultérieurement, à

mesure que le processus de conception de la base de données continue de se

dérouler.
Composer les descriptions des tableaux

La description du tableau est un autre aspect d'un tableau que vous

enregistrez dans la liste des tableaux finaux. Une description de table est

cruciale car elle aide chacun à comprendre pourquoi une table donnée existe et

pourquoi l'organisation souhaite collecter les données de cette table. En fait, la

description doit définir explicitement le tableau et indiquer son

importance pour l'organisation. Peu importe que la définition vienne en premier

ou que vous utilisiez plus d'une phrase pour transmettre cette information. La

définition et l'explication de l'importance du tableau doivent figurer dans la

description. La description du tableau fournit également un moyen de valider la

nécessité d'un tableau. Si vous ne parvenez pas à expliquer pourquoi un

tableau est important pour l'organisation, vous devez alors déterminer quand

et comment le tableau a été identifié et s'il est nécessaire.

Lignes directrices pour composer une description de tableau

Tout comme vous disposiez de directives pour vous aider à définir les noms de

table, vous disposez également d'un ensemble de directives pour vous aider à

rédiger une description de table ciblée, concise, sans ambiguïté et claire :

• Incluez une déclaration qui définit avec précision le tableau. N'importe qui

devrait facilement être en mesure de déterminer l'identité de la table à

partir de sa description, sans aucune confusion ni incertitude. Voici un

exemple de mauvaise définition d'une table nommée « Fournisseurs » dans

une base de données de boulangerie. Comme vous pouvez le constater, ce

n'est pas très précis :

Fournisseurs : les entreprises qui nous fournissent des ingrédients et des

équipements
 Et si la boulangerie recevait certains de ses ingrédients auprès de petits

agriculteurs locaux ? Les petits agriculteurs ne sont certainement pas

considérés comme des « entreprises ». Quel type d’équipement ces

fournisseurs fournissent-ils ? Ustensiles de cuisine? Des diables ? Des

supports de livraison ? Voici une bien meilleure définition des fournisseurs :

Fournisseurs : les personnes et les organisations auprès desquelles nous

achetons des ingrédients et des équipements.

Cette instruction peut être utilisée dans la description de la table

comme définition de la table.

• Incluez une déclaration expliquant pourquoi ce tableau est important pour

l’organisation. Une table contient des données collectées, conservées,

manipulées et récupérées par l'organisation pour une

raison particulière . Votre déclaration doit expliquer pourquoi les données

sont importantes pour l'organisation. En gardant à l’esprit que cette

instruction fait partie de la description de votre table, vous pourriez être

tenté de construire une instruction telle que celle-ci :

Nous avons besoin de la table Fournisseurs pour garder une trace des noms,

adresses, numéros de téléphone et noms de contacts de tous nos

fournisseurs.

Cette déclaration est inadéquate car elle met uniquement l'accent sur ce

qui doit être stocké dans la table Fournisseurs au lieu

d'amplifier pourquoi les données sont importantes pour

l'entreprise. L’exemple suivant donne une meilleure idée de l’importance de

l’information :

Les informations sur les fournisseurs sont vitales pour la boulangerie car

elles nous permettent de maintenir un approvisionnement constant en

ingrédients et de garantir que nos équipements sont toujours en état de

marche.
 Il s'agit d'une déclaration plus efficace car elle traduit l'importance des

données en identifiant les services que les fournisseurs fournissent à la

boulangerie. Cela implique également que la boulangerie pourrait manquer

d'ingrédients ou avoir du mal à maintenir son équipement en parfait état

sans les services des fournisseurs. Cette déclaration reflète désormais

pourquoi la table est importante pour l'organisation.

• Rédigez une description claire et succincte. Évitez l'erreur courante

consistant à reformuler ou à reformuler le nom de la table dans la

description de votre table, comme dans cet exemple :

Horaire de l'étudiant : l'horaire de cours de l'étudiant

Ne soyez pas trop bref ou trop verbeux. Vous voulez vous assurer que tout le

monde peut identifier le tableau et comprendre son importance pour

l'organisation, mais vous voulez également éviter de fournir trop

d'informations. Voici un exemple de description assez longue et fournissant

plus d'informations que nécessaire :

Horaire des étudiants : tous les cours auxquels un étudiant assistera (y

compris les jours, les heures et le professeur qui dirige le cours) au cours de

l'année scolaire. Les données de ce tableau sont importantes car elles

permettront à l'élève de connaître le nom de la classe ainsi que l'heure et

l'endroit où il est censé se trouver. De plus, l'étudiant connaîtra la durée du

cours, ainsi que le nom de l'enseignant qui enseigne le cours.

Cela peut être reformulé de manière plus claire et succincte comme suit :

Horaire de l'élève : cours auxquels l'élève doit assister au cours de cette

année scolaire. Les informations fournies par ce tableau aident l'élève à

mettre en œuvre une gestion efficace du temps et permettent à l'école de

comprendre la charge de classe et la charge de travail des élèves.

La première phrase de cet exemple fournit la définition du tableau et la

deuxième phrase indique pourquoi le tableau est important pour

l'organisation universitaire.
• N'incluez pas d'informations spécifiques à l'implémentation dans la

description de votre table, telles que la manière et l'endroit où la table est

utilisée. Évitez les déclarations indiquant comment vous utiliserez
spécifiquement cette table ou comment vous y accéderez physiquement. Ce

type d'informations concerne le processus de mise en œuvre de la base de

données , qui est totalement distinct du processus de conception de base

de données que vous apprenez dans ce livre. Voici un exemple de

description contenant ce type d’informations inappropriées :

Horaire de l'élève : cours auxquels l'élève doit assister au cours de cette

année scolaire. Ces informations sont utilisées par le registraire et sont

accessibles à partir du menu Admissions des étudiants dans le programme

d'inscription.

• Ne faites pas dépendre la description d’une table de la description d’une

autre table. Chaque description de tableau doit être explicite et

indépendante de toute autre description de tableau ; il ne devrait

absolument pas être nécessaire de croiser les descriptions d'une table avec

une autre. C'est le type de déclaration que vous essayez d'éviter :

Personnes à charge : le conjoint, les enfants ou les pupilles d'un employé

donné. (Voir la description de la table Employé pour plus d'informations.)

Voici une bien meilleure description :

Personnes à charge : le conjoint, les enfants ou les pupilles d'un employé

donné. Ces informations nous permettent d'effectuer les déductions fiscales

appropriées pour l'employé et sont nécessaires aux programmes

d'avantages sociaux auxquels l'employé est inscrit.

• N'utilisez pas d'exemples dans une description de tableau. Un exemple est

un outil de communication précieux qui vous aide à transmettre une

signification ou un concept particulier et qui est très efficace lorsque vous

l’utilisez judicieusement. Cependant, un exemple dépend d’informations

supplémentaires (et, dans certains cas, d’autres exemples) pour compléter

l’idée qu’il est censé véhiculer. Par exemple, pensez simplement au nombre

d’exemples que vous devrez utiliser pour définir pleinement ce que

représente un tableau. Une description bien définie est claire, succincte et

explicite ; par conséquent, il n’a pas besoin d’un exemple pour transmettre

sa signification.
Interviewer les utilisateurs et la direction

Vous allez maintenant définir les descriptions des tables de la liste des tables

finales. Vous mènerez des entretiens avec les utilisateurs et la direction et

solliciterez leur aide pour établir la définition et l'importance de chaque table

pour l'organisation. (C'est l'une des rares fois où vous interviewerez les deux

groupes ensemble.) Votre objectif principal est d'obtenir un consensus sur les

descriptions générales des tableaux. Une fois vos entretiens terminés, prenez

vos notes et rédigez les descriptions de la table finale, en veillant à suivre les

directives décrites plus haut dans ce chapitre. Discutez ensuite à nouveau avec

les deux parties pour vous assurer que les descriptions sont acceptables et

faciles à comprendre par tous. La liste de la table finale est complète lorsque

tout le monde s'est mis d'accord sur les descriptions.

Prenons cet exemple : supposons que vous développez une base de données

pour un organisme local de formation en logiciels. Votre assistant, John, mène

un entretien avec certaines personnes de l'organisation. Plus précisément, il

parle à Mark du service administratif ; Jason, le coordinateur des

instructeurs ; Sara, la vice-présidente des ventes ; et Carol, lachef de

l'organisation. Le dialogue qui suit est une transcription partielle de l'entretien

de John. John discute actuellement de la table des étudiants.

Note

Contrairement aux entretiens que vous avez menés lors des étapes d’analyse

et d’examen des exigences du processus de conception, vous n’avez plus

besoin d’impliquer tout le monde dans l’organisation. Cependant, vous

travaillerez avec un groupe représentatif d'utilisateurs et de direction pour les

entretiens que vous mènerez tout au long du processus de conception.

JOHN :« D'accord, parlons de la table des étudiants. Comment décririez-vous un

« étudiant » ?

J ASON :« Un étudiant est un particulier qui vient suivre un de nos cours. »

SAR :« Ce n'est que partiellement vrai. Un étudiant peut également être une

personne qu’une organisation envoie à nos cours. Par exemple, beaucoup de

nos étudiants viennent de banques et de compagnies d'assurance locales, et

ces organisations paient les frais de scolarité des étudiants.

MARQUE :"Logique. Je suppose que nous pouvons simplement dire qu’un

étudiant est une personne qui vient à l’un de nos cours.

(John prend note de ce que Mark vient de dire.)

JOHN :"Bien, je l'ai compris. Quelqu'un a-t-il autre chose à ajouter ?

(Pause…)
"Super. Maintenant, comment expliqueriez-vous à quelqu’un pourquoi les

informations sur les étudiants sont importantes pour cette organisation ? »

CAROL :« Sans étudiants, nous n'avons pas d'entreprise !

J ASON :« Si nous pouvons suivre les étudiants qui fréquentent nos cours, nous

pouvons leur envoyer des informations concernant nos nouveaux cours. »

SAR :« Garder une trace de ces informations nous permet de maintenir à jour

les informations de facturation et de contact. Cela est particulièrement vrai

pour les organisations qui envoient leurs employés suivre nos cours. Les

coordinateurs de formation évoluent vers d'autres postes et il faut connaître le

nom de la nouvelle personne avec qui nous aurons affaire.

JOHN :"Bon point. Quelqu'un a-t-il quelque chose à ajouter ? D'accord, est-ce

que tout le monde est d'accord avec ce qui a été dit jusqu'à présent ?

(Tout le monde hoche la tête en signe d'approbation. Comme aucun

commentaire supplémentaire n'est fait, John prend quelques notes finales et

passe au tableau suivant.)

Comme vous pouvez le constater, mener ce type d’entretien est une affaire

assez simple. Remarquez comment John tente d'obtenir un consensus en

reconnaissant que personne n'a autre chose à dire sur le sujet en question. Il

note ensuite les points qui l'aideront à rédiger la description et passe à son

sujet suivant.

Une fois que John a fini de mener l’entretien, il utilise ses notes pour élaborer

une description de chaque table de la liste finale des tables. Il devra interpréter

et étudier les réponses des participants pour élaborer une description de

tableau adaptée. Sur la base de son examen, John rédige la description

suivante :
Étudiants : les personnes qui assistent à nos cours. Les informations fournies

par les données du tableau Étudiants permettent à notre organisation de

promouvoir davantage nos cours et soutiennent une bonne communication

avec les étudiants.

John écrit ensuite une description pour chaque table de la liste des tables

finales. Lorsqu'il aura terminé, il parlera à nouveau avec Mark, Jason, Sara et

Caroline pour s'assurer que les descriptions sont acceptables et que tout le

monde les comprend sans aucune difficulté.

Association de champs à chaque table

Au chapitre 3 , vous avez appris que les tables sont composées de champs. Au

cours de cette étape du processus de conception de la base de données, vous

attribuerez des champs à chaque table de la liste des tables finales à l'aide des

champs de votre liste de champs préliminaire.

L'attribution de champs à une table est un processus relativement simple :

déterminez quels champs représentent le mieux les caractéristiques du sujet

de la table et affectez-les à cette table. Répétez cette procédure pour chaque

table de la liste des tables finales. Si vous pensez pouvoir utiliser un champ ou

un ensemble de champs pour représenter les caractéristiques de plusieurs

tables, attribuez-les en conséquence. Vous découvrirez plus tard si vous avez

attribué les champs appropriés à chaque table lorsque vous affinerez les

structures des tables.

Note
Dans les exemples suivants, vous remarquerez que je vous demande d'utiliser

des feuilles de papier pour des procédures spécifiques. L'utilisation du papier

vous aide à éviter la tentation d'utiliser un programme SGBDR pour concevoir

votre base de données. Je ne saurais trop insister ou exagérer sur le fait que

vous ne devez pas utiliser l'ordinateur du tout tant que le processus de

conception de base de données n'est pas terminé, à moins que vous n'utilisiez

un type de logiciel spécifique à la conception de base de données . En tenant

compte de ces conseils, vous éviterez les pièges dont je parlerai plus loin

dans le chapitre 14 , « Mauvaise conception : ce qu'il ne faut pas faire ».

Commencez ce processus en prenant une feuille de papier et en la posant

devant vous dans le sens de la longueur, de gauche à droite. Écrivez le nom de

chaque table (de la liste des tables finales) en haut de la feuille, en

commençant par le côté gauche ; laissez suffisamment d'espace entre les

noms de table pour vous donner suffisamment d'espace pour lister les noms de

champs longs en dessous. Répétez cette procédure en utilisant autant de

feuilles que nécessaire pour tenir compte de chaque tableau de la

liste. Poursuivant avec l'exemple de la base de données scolaire, la figure

7.10 montre l'ensemble des structures de tables actuellement en cours de

développement.
Figure 7.10 Configuration d'une feuille pour lister les structures de table.

Ensuite, attribuez les champs de la liste de champs préliminaire à chaque

table. Déterminez quels champs décrivent ou définissent le mieux le sujet

d'une table, puis répertoriez ces champs sous le nom de la table. Après avoir

attribué tous les champs que vous jugez appropriés pour le tableau, passez au

tableau suivant et répétez le processus. Continuez de cette manière jusqu'à ce

que vous ayez attribué des champs à toutes les tables. La figure 7.11 montre

un ensemble partiel de structures de tables.

Figure 7.11 Liste des tables avec leurs champs associés.

Note

Avant de parcourir le reste du chapitre, c’est le bon moment pour rappeler un

principe que j’ai présenté dans l’introduction :

Concentrez-vous sur le concept ou la technique et les résultats escomptés, et

non sur l'exemple utilisé pour l'illustrer.

Je porte à nouveau cela à votre attention car vous vous demanderez

certainement pourquoi j'ai créé un exemple d'une manière particulière. Peut-

être avez-vous pensé à une approche différente ou meilleure du problème, et

vous avez peut-être des raisons tout à fait valables de l'utiliser. Ne vous laissez

pas induire en erreur par l'exemple. J'ai façonné chaque exemple d'une

manière spécifique dans le seul but d'illustrer le concept ou la technique en

question. Par conséquent, étudiez la manière dont je corrige les problèmes que

vous voyez dans un exemple particulier afin de pouvoir utiliser ces techniques

lorsque vous rencontrez des problèmes similaires dans votre base de données.

Affiner les champs

Maintenant que vous avez attribué des champs à chaque table, vous allez

affiner les champs en améliorant les noms des champs et en résolvant les

problèmes structurels pouvant exister. Vous affinerez ensuite davantage les

tableaux en vérifiant que vous avez attribué les champs appropriés à chaque

table et que les structures des tableaux sont solides.

Améliorer les noms de champs

Comme vous le savez, un champ représente une caractéristique du sujet de la

table à laquelle il appartient. Vous pouvez facilement identifier la

caractéristique qu'un champ est censé représenter lorsque ce champ porte un

nom approprié. Un nom de champ ambigu, vague ou peu clair est un signe

certain de problème et suggère que vous n'avez pas complètement identifié

l'objectif du champ.
Lignes directrices pour la création de noms de champs

Plus tôt dans ce chapitre, vous avez appris un ensemble de directives pour

nommer une table. Vous allez maintenant apprendre un autre ensemble de

directives que vous appliquerez aux noms de champs. Heureusement,

beaucoup d’entre eux sont similaires aux directives régissant les noms de

tables, vous connaissez donc déjà la plupart des concepts :

• Créez un nom unique et descriptif qui ait du sens pour l'ensemble de

l'organisation. Un nom de champ donné ne doit apparaître qu'une seule fois

dans l'ensemble de la base de données ; la seule exception à cette règle se

produit lorsque le champ sert à établir une relation entre deux

tables. Assurez-vous que le nom est suffisamment descriptif pour

transmettre sa signification avec précision à tous ceux qui le voient. ( Le

chapitre 10 aborde cette question plus en détail.)

• Créez un nom qui identifie avec précision, clarté et sans ambiguïté la

caractéristique qu'un champ représente. « Numéro de téléphone » est un

bon exemple de nom de champ inexact et ambigu. Quel type de numéro de

téléphone représente-t-il ? Un téléphone fixe ? Un téléphone de bureau ? Un

téléphone cellulaire? Apprenez à être précis. Si vous devez enregistrer

chacun de ces types de numéros de téléphone, créez les champs «

Téléphone personnel », « Téléphone professionnel » et « Téléphone portable

».
Au chapitre 6 , « Analyse de la base de données actuelle », vous avez appris

à résoudre les noms de champs génériques, tels que « Adresse », « Ville » et

« État », en utilisant le nom de la table comme préfixe pour le nom du

champ. Cela produit des noms tels que « Adresse de l'employé », «

Adresse du client » et « Adresse du fournisseur ». Lorsque vous disposez de

noms de champs tels que ceux-ci, vous pouvez abréger le préfixe (par souci

de concision) en utilisant les trois ou quatre premières lettres du nom de la

table comme préfixe révisé. Cela vous permet de transformer les noms de

champs précédents en « Adresse Emp », « Adresse Cust » et «

Adresse Supp ». Cette technique vous aide à respecter non seulement cette

directive, mais également la précédente.

Note

La mesure dans laquelle vous utilisez les préfixes dans un tableau est une

question de style. Lorsqu'une table contient des noms de champs

génériques, certains concepteurs de bases de données choisissent de

préfixer uniquement les noms génériques, tandis que d'autres choisissent

de préfixer tous les noms de champs de la table. Quelle que soit la méthode

de préfixe que vous choisissez d’utiliser, il est très important de l’utiliser de

manière cohérente dans toute la structure de la base de données.

Personnellement, je préfère préfixer uniquement les noms de champs

génériques, et je suivrai cette préférence dans le reste du livre.

• Utilisez le nombre minimum de mots nécessaire pour transmettre la

signification de la caractéristique représentée par le champ. Vous souhaitez

éviter les noms de champs longs, mais en même temps, vous souhaitez

également éviter d'utiliser un seul mot comme nom de champ si ce mot est

inapproprié. Par exemple, si vous essayez d'enregistrer la date à laquelle un

employé particulier a rejoint l'organisation, « Embauché » est trop court (et

légèrement vague) et « Date d'embauche de l'employé » est trop

longue ! « Date d'embauche » est cependant un nom plus approprié et

représente avec précision la caractéristique que représente le champ.

• N’utilisez pas d’acronymes et utilisez les abréviations judicieusement. Les

acronymes peuvent être difficiles à déchiffrer et prêtent souvent à des

malentendus. Imaginez un champ nommé « CAD_SW ». Comment

détermineriez-vous ce que représente le champ ? En revanche, vous pouvez

utiliser des abréviations à condition de les utiliser avec parcimonie et de les

manipuler avec précaution. N'utilisez une abréviation que si elle complète

ou améliore le nom du champ de manière positive. Une abréviation ne doit

pas rendre un nom de champ ambigu ni diminuer sa signification.

• N'utilisez pas de mots qui pourraient confondre la signification du nom du

champ. Un nom de champ contenant des mots ou des synonymes

redondants peut rendre la signification du nom floue et sujette à une

mauvaise interprétation. Par exemple, considérons le nom « Numéro de

code d’identification numérique ». « Numérique » et « numéro » sont

redondants, vous pouvez donc éliminer l'un ou l'autre sans diminuer la

signification du nom du champ.Supposons que vous décidiez d’éliminer le

« numérique ». Vous pouvez diviser le nom restant en deux noms plus

petits : « Code d'identification » et « Numéro d'identification ». Ces noms

sont souvent synonymes et vous pouvez facilement les utiliser comme nom

de champ final. Dans cette situation, utilisez simplement le nom le plus

significatif au sein de l’organisation.

• N'utilisez pas de noms qui identifient implicitement ou explicitement plus

d'une caractéristique. Ces types de noms sont faciles à repérer car ils
utilisent généralement le mot et ou ou. Les noms de champs qui

contiennent une barre oblique (\) ou une esperluette (&) sont également des

indices inutiles. Lorsque vous rencontrez un champ portant un nom tel que «

Zone ou emplacement » ou « Téléphone\Fax », identifiez chaque

caractéristique que le nom implique et créez un nouveau champ pour la

caractéristique. Testez ensuite le nouveau nom de champ par rapport à ces

directives pour vous assurer que le nom est correct.

• Utilisez la forme singulière du nom. Un champ avec un nom au pluriel, tel

que « Compétences », implique qu'il peut contenir deux valeurs ou plus

pour un enregistrement donné, ce qui n'est pas une bonne idée. (Vous en

apprendrez davantage à ce sujet plus loin dans le chapitre.) Un nom de

champ est singulier car il représente une seule caractéristique du sujet de la

table à laquelle il appartient. En revanche, un nom de table est au pluriel car

il représente une collection d’objets ou d’événements similaires. Vous

pouvez distinguer assez facilement les noms de tables des noms de champs

lorsque vous utilisez cette convention de dénomination.

Note

La directive spécifique pour l'utilisation d'un nom de table comme préfixe pour

un nom de champ aura le même problème que celui que j'ai évoqué plus tôt

pour les noms de table : ces noms de champs particuliers sont susceptibles de

changer une fois que vous (ou le développeur de base de données en charge

de l'implémentation de la base de données) ) commencez à implémenter la

base de données dans une application SGBDR spécifique. Les noms devront

être conformes aux conventions de dénomination standard de votre

organisation ou que les développeurs utilisent couramment pour le SGBDR.

En gardant ces directives à l’esprit, examinez chaque table et déterminez si

vous pouvez apporter des améliorations à l’un des noms de champ. Lorsque

vous avez terminé, vous êtes prêt à identifier et à résoudre tout problème lié

aux champs. La figure 7.12 montre les révisions apportées aux noms de

champs des structures de table de la figure 7.11 .

Dans la figure 7.12 , « Classes » est raccourci en « Cls », « Sujets » est

raccourci en « Sujet », « Instructeurs » est raccourci en « Inst », « Étudiant »

est raccourci en « Std » et « Numéro de sécurité sociale » remplace

« SSN ». N'oubliez pas que les abréviations peuvent être très utiles à condition

qu'elles soient significatives et comprises par tous les membres de

l'organisation. L’utilisation d’abréviations appropriées n’enlèvera rien à la

signification du nom du champ.

Figure 7.12 Noms de champs révisés.

Note
Dans le reste du chapitre et dans le reste du livre, les noms de tables dans le

texte apparaissent en lettres majuscules (comme VENDORS) et les noms de

champs dans le texte apparaissent en petites lettres majuscules (comme V

ENDOR ID N UMBER ).

Utiliser un champ idéal pour résoudre les anomalies

Bien que vous ayez soigneusement identifié les champs de votre liste de

champs préliminaire, vous avez peut-être créé quelques champs qui pourraient

s'avérer problématiques pour la structure de la table. Des champs mal définis

peuvent entraîner des données en double et des données redondantes, et ils

peuvent être difficiles à utiliser. Vous aurez peut-être du mal à déterminer si

l'un des champs d'une table va poser des problèmes à moins de connaître les

signes avant-coureurs. La meilleure façon d'identifier les champs

potentiellement problématiques est de déterminer s'ils sont conformes aux

éléments du champ idéal, comme indiqué ci-dessous.

Éléments du champ idéal

Les éléments du champ idéal constituent un ensemble de lignes directrices que

vous pouvez utiliser pour créer des structures de champ sonore et repérer

facilement les champs mal conçus. Un champ idéal présente les

caractéristiques suivantes :

• Il représente une caractéristique distincte du sujet du tableau. Comme vous

le savez, un tableau représente un sujet précis, qui peut être un objet ou un

événement. Le champ idéal représente une caractéristique distincte de cet

objet ou événement.
• Il ne contient qu'une seule valeur. Un champ pouvant potentiellement

stocker deux occurrences ou plus de la même valeur est appelé champ à

valeurs multiples . Un champ à plusieurs valeurs entraîne des problèmes de

redondance des données (de toute évidence) et est difficile à utiliser lorsque

vous essayez de modifier, supprimer ou trier les données qu'il contient. Le

champ idéal est exempt de ces problèmes car il ne contient qu’une seule

valeur.

• Il ne peut pas être déconstruit en composants plus petits. Un champ qui

peut potentiellement stocker deux éléments distincts ou plus dans une

valeur est appelé champ en plusieurs parties (ou composite). Comme le

champ à valeurs multiples, ce type de champ pose des problèmes lorsque

vous essayez de modifier, supprimer ou trier les données qu'il contient. Ces

problèmes ne se produisent pas avec un champ idéal car il représente une

caractéristique unique et distincte du sujet de la table à laquelle il

appartient. (Vous en apprendrez davantage sur les champs à valeurs

multiples et en plusieurs parties dans un instant.)

• Il ne contient pas de valeur calculée ou concaténée. Les valeurs des champs

d'une table doivent être mutuellement indépendantes ; un champ particulier

ne devrait pas avoir à dépendre des valeurs d'autres champs pour sa propre

valeur. Cependant, un champ calculé dépend des valeurs d’autres champs

pour sa propre valeur, et c’est là que réside le problème. La valeur du

champ calculé n'est pas mise à jour lorsque la valeur d'un champ participant

au calcul change. Il incombe alors à l'utilisateur ou au programme

d'application de base de données (et constitue une charge indésirable) de

mettre à jour le champ calculé lorsque ce type de changement se

produit. C'est précisément pourquoi vous traitez les champs calculés

séparément.
• Il est unique dans toute la structure de la base de données. Les seuls

champs en double qui apparaissent dans une base de données

correctement conçue sont ceux qui établissent des relations entre les

tables. Si des champs en double autres que ceux-ci existent dans une table,

il est très probable que la table accumule des données redondantes inutiles

et que les données contenues dans les champs en double deviennent

inévitablement incohérentes.

Note

N'oubliez pas qu'à ce stade, vous traitez strictement de la structure logique

de la base de données. Vous pourriez être amené à dupliquer des champs

spécifiques lorsque vous implémentez physiquement la base de données

dans un programme SGBDR. Cependant, au cours de ce processus, vous

prenez la décision consciente de dupliquer les champs et vous êtes prêt à

faire face aux conséquences de cette décision.

• Il conserve la majorité de ses propriétés lorsqu'il apparaît dans plusieurs

tableaux. Un champ qui établit une relation entre deux tables est un
composant structurel de chaque table. La majorité des propriétés du champ

restent constantes à chaque occurrence du champ. ( Le chapitre 9 ,

« Spécifications de terrain » et le chapitre 10 traitent de cette question plus

en détail.)

Bien que vous connaissiez désormais les éléments spécifiques d'un domaine

idéal, vous aurez toujours du mal dans de nombreux cas à identifier les champs

problématiques simplement en regardant leurs noms. La figure 7.13 montre

une structure de tableau qui aide à illustrer ce point. Prenez un moment et

essayez de déterminer si chaque champ est conforme aux éléments du champ

idéal ou doit être modifié.

Figure 7.13 Un tableau contenant des champs avec des structures douteuses.

Chaque champ de la liste semble être conforme aux éléments du champ

idéal. Examinez cependant attentivement la liste et vous verrez que certains

champs ne respectent pas vraiment les deuxième et troisième éléments. Trois

champs présentent des anomalies qui poseront des problèmes à moins que

vous ne les résolviez : I NST NOM , I NST ADRESS et C ATEGORIES T AUGHT . Si vous

doutez de cette affirmation, vous pouvez la tester en « chargeant » le tableau

avec des exemples de données. Cela révélera rapidement les anomalies, le cas

échéant, et constitue le meilleur moyen de confirmer si un champ est conforme

à tous les éléments du champ idéal.

Vous n'avez pas besoin de créer physiquement une table pour effectuer ce

test. Prenez une feuille de papier et posez-la devant vous dans le sens de la

longueur, de gauche à droite. Écrivez le nom de chaque champ en haut du

papier, en commençant par le côté gauche ; laissez suffisamment d'espace

entre les noms de champs pour laisser de la place aux valeurs que vous allez

placer en dessous.Entrez les enregistrements dans le tableau en remplissant

chaque champ avec quelques exemples de données ; assurez-vous que les

exemples de données représentent les données que vous allez réellement

saisir dans la base de données. Vous n’avez besoin que de quelques

enregistrements pour que le test fonctionne correctement. Votre feuille de

papier doit ressembler à celle de la figure 7.14 .

Figure 7.14 Test d'un tableau sur papier avec des exemples de données.

Note

Comme je l'ai mentionné au chapitre 3 , je montre uniquement les champs les

plus pertinents pour la discussion en cours et j'utilise « autres champs » pour

représenter les champs qui ne sont pas essentiels à l'exemple.

Vous pouvez désormais facilement identifier les champs qui poseront problème

à moins qu'ils ne soient résolus. Comme vous pouvez le voir, I NST N AME et

I NST A DDRESS sont tous deux des champs à plusieurs parties, et

C ATEGORIES T AUGHT est un champ à plusieurs valeurs. Vous devez résoudre ces

champs avant de pouvoir affiner la structure de la table.

Résolution des champs multiparties

Travailler avec un champ multipart est difficile car sa valeur contient deux

éléments distincts ou plus . Il est difficile de récupérer des informations à partir

d'un champ en plusieurs parties, et il est difficile de trier ou de regrouper les

enregistrements de la table en fonction de la valeur du champ. Le champ

I NST A DDRESS de la figure 7.14 illustre ces difficultés ; vous auriez certainement

des difficultés à récupérer des informations sur la ville de Seattle ou à trier les

informations par code postal.

Vous résolvez un champ en plusieurs parties en identifiant les éléments

distincts dans la valeur du champ et en traitant chaque élément comme un

champ individuel.

Accomplissez cette tâche en vous posant une question simple : « Quels

éléments spécifiques représente la valeur de ce champ ? » Après avoir répondu

à la question et identifié les éléments (du mieux que vous pouvez), transformez

chaque élément en un nouveau champ.

Dans la Figure 7.14 , la valeur du champ I NST N AME représente deux éléments :

le prénom et le nom d'un instructeur. Vous résolvez ce champ en créant un

nouveau champ I NST FIRST N AME et un nouveau champ I NST L AST N AME . La

valeur de I NST A DDRESS représente quatre éléments : l'adresse postale, la ville,

l'état et le code postal d'un instructeur. Vous transformez également ces

éléments en champs ; ils apparaîtront dans le tableau sous les noms

I NST S TREET A DDRESS ,I NST C ITY ,I NST S TATE et I NST Z IPCODE . La figure

7.15 montre le tableau INSTRUCTEURS récemment révisé.

Figure 7.15 Résolution des champs en plusieurs parties dans la table

INSTRUCTORS.
Certains champs en plusieurs parties sont difficiles à reconnaître. Jetez un œil

au tableau INSTRUMENTS de la figure 7.16 . À première vue, le tableau ne

semble pas contenir de champs en plusieurs parties. Toutefois, lorsque vous

examinez les données du tableau de plus près, vous constaterez que

I NSTRUMENT ID est en réalité un champ en plusieurs parties. La valeur de ce

champ représente deux éléments distincts : la catégorie à laquelle appartient

l'instrument — AMP (amplificateur), GUIT (guitare), MFX (unité multi-effets),

SFX (unité à effet unique) — et le numéro d'identification de l'instrument. De

toute évidence, vous devez déconstruire I NSTRUMENT ID en deux champs plus

petits conformément au troisième élément d'un champ idéal. Imaginez à quel

point il vous serait difficile de mettre à jour la valeur du champ si la catégorie

MFX devenait MFU si vous ne le faisiez pas. Vous devrez écrire du code de

programmation pour analyser la valeur, tester l'existence de MFX, puis le

remplacer par MFU s'il existait dans levaleur analysée. Ce n'est pas tant que

vous ne pouvez pas faire cela, mais vous travailleriez certainement plus dur

que nécessaire, et vous ne devriez pas avoir à le faire du tout si vous disposez

d'une base de données correctement conçue.

Figure 7.16 Un exemple de champ multipart « caché ».

Résolution de champs à valeurs multiples

Comme vous le savez, un champ à plusieurs valeurs peut potentiellement

stocker deux ou plusieurs occurrences de la même valeur. Heureusement, vous

reconnaîtrez un champ à plusieurs valeurs lorsque vous en verrez un. Le nom

du champ est souvent au pluriel et sa valeur contient presque invariablement

un certain nombre de virgules, qui servent à séparer les différentes

occurrences qui existent au sein de la valeur elle-même.

La résolution de champs à plusieurs parties n'est pas très difficile du tout, mais

la résolution de champs à plusieurs valeurs peut être un peu plus difficile et

demandera du travail. Un corps à valeurs multiples présente le même

ensemble fondamental de problèmes qu'un corps à plusieurs parties, comme

l'illustre clairement le champ CATEGORIES ENSEIGNÉES de la figure 7.17 . Par

exemple, vous aurez du mal à récupérer des informations sur tous ceux qui

enseignent une catégorie spécifique (telle que WP), vous ne pourrez pas trier

les données de manière significative et, plus important encore, vous ne pourrez

pas trier les données.avoir la possibilité de participer à plus de quatre

catégories. Que se passe-t-il lorsqu'un ou plusieurs instructeurs

enseignent cinq catégories ? La seule option dont vous disposez est d'agrandir

le champ chaque fois que vous devez saisir plus de valeurs que ce qu'il

autorise actuellement.

Figure 7.17 Identification d'un champ à valeurs multiples.

Alors, comment résoudriez-vous ce champ à valeurs multiples ? Votre première

idée sera peut-être de créer un nouveau champ pour chaque valeur, «

aplatissant » ainsi le champ à plusieurs valeurs en plusieurs champs à valeur

unique. La figure 7.18 montre ce qui se passera si vous suivez cette idée.

Figure 7.18 Résultat de « l’aplatissement » du champ C ATEGORIES ENSEIGNÉES .

Malheureusement, ce n’est pas vraiment une amélioration. Trois problèmes

spécifiques découlent de ce type de structure :

1. Récupérer des informations sur les catégories sera au mieux fastidieux. Un

utilisateur qui tente de trouver tous les instructeurs qui enseignent la

catégorie WP doit s'assurer de rechercher cette valeur dans chacune des

catégories.des champs; il n'y a aucune garantie que WP soit

systématiquement stocké dans le même champ. Dans le cas contraire,

l'utilisateur court le risque de négliger un instructeur qualifié.

2. Il n'existe aucun moyen pour le programme RDBMS de trier les données de

catégorie de manière significative.

3. Cette structure est intrinsèquement volatile. Dans son état actuel, le

tableau restreint inutilement le nombre de catégories qu'un instructeur peut

enseigner ; vous devez créer des champs de catégorie supplémentaires

lorsque vos instructeurs enseignent plus de trois catégories. L'ajout de

champs de catégorie supplémentaires ne fait qu'aggraver les deux premiers

problèmes.
Réalisant que l'aplatissement du champ CATÉGORIES ENSEIGNÉES ne résoudra

pas votre problème, votre prochaine pensée est de mettre le champ en

conformité avec le deuxième élément d'un champ idéal et de déclarer qu'il ne

contiendra qu'une seule valeur . Bien qu’il s’agisse d’une bonne impulsion et

d’un pas dans la bonne direction, cela ne résoudra pas complètement le

problème car cela introduira encore un autre problème : la redondance des

données. La figure 7.19 illustre ce qui se passe lorsque vous donnez suite à

cette idée particulière. Notez qu'il n'y a désormais qu'une seule valeur dans le

champ CATEGORIES ENSEIGNÉES pour chaque enregistrement de la table.

Figure 7.19 Résultat de la mise en conformité des

CATEGORIES ENSEIGNÉES avec le deuxième élément d'un domaine idéal.

Les valeurs dans CATEGORIES ENSEIGNEES provoquent des données redondantes

car vous devez dupliquer un enregistrement d'instructeur donné pour chaque

catégorie enseignée par l'instructeur . Cette redondance est évidemment

inacceptable, vous devrez donc résoudre ce problème d'une autre manière.
Vous pouvez éviter complètement cette situation en suivant ces étapes pour

résoudre un champ à plusieurs valeurs :

1. Supprimez le champ de la table et utilisez-le comme base pour une nouvelle

table. Si nécessaire, renommez le champ conformément aux instructions de

nom de champ que vous avez apprises plus tôt dans ce chapitre.

2. Utilisez un champ (ou un ensemble de champs) de la table d'origine pour

associer la table d'origine à la nouvelle table ; essayez de sélectionner des

champs qui représentent le plus fidèlement possible le sujet du

tableau. Le(s) champ(s) que vous choisissez apparaîtront dans les deux

tableaux. (Vous en apprendrez davantage sur la relation entre les tables

au chapitre 10. )

3. Attribuez un nom, un type et une description appropriés à la nouvelle table

et ajoutez-la à la liste des tables finales.

Ces étapes constituent une procédure générique que vous pouvez utiliser pour

résoudre tout champ à valeurs multiples que vous rencontrez dans une

table. Maintenant, appliquez ces étapes au champ CATEGORIES ENSEIGNÉES .

1. Supprimez le champ de la table INSTRUCTORS et utilisez-le comme base

d'une nouvelle table. Comme il s'agira désormais d'un champ à

valeur unique , renommez le champ C ATEGORY T AUGHT .

2. Utilisez I NST FIRST N AME et I NST L AST N AME comme champs de connexion

qui relieront la table INSTRUCTORS à la nouvelle table et les ajouteront à la

structure de la nouvelle table .

3. Donnez un nom propre à la nouvelle table, rédigez une description

appropriée et ajoutez la table à la liste des tables finales. (Indiquez letype

de table comme « Données ».) Voici un nom et une description possibles

que vous pourriez utiliser pour la nouvelle table :

 Catégories d'instructeur : catégories de logiciels qu'un instructeur est

qualifié pour enseigner. Les informations fournies par ce tableau nous

permettent de nous assurer qu'il existe un nombre adéquat d'instructeurs

pour chaque catégorie de logiciels.

La figure 7.20 montre le tableau INSTRUCTEURS révisé et le nouveau tableau

CATÉGORIES D'INSTRUCTEURS.

Figure 7.20 Résolution du champ à valeurs multiples dans la table

INSTRUCTORS.
Notez que la nouvelle table INSTRUCTOR CATEGORIES est exempte des

problèmes généralement associés aux champs à valeurs multiples car

C ATEGORY T AUGHT est un champ à valeur unique . Vous pouvez facilement

récupérer des informations sur un instructeur ou une catégorie particulière et

trier les enregistrements de manière significative. Notez également que

les champs I NST PREMIER NOM et I NST LAST Les champs N AME conservent leurs

noms dans la nouvelle table, ce qui les rend conformes au cinquième élément

d'un champ idéal.

Bien que la nouvelle table contienne des données redondantes, la redondance

est acceptable car minime. C'est un fait : une base de données relationnelle

contiendra toujours une certaine quantité de données redondantes. Votre

objectif en tant qu'architecte de base de données est de vous assurer qu'elle

ne contient qu'un minimum absolu de données redondantes.

La figure 7.21 montre une version de la table INSTRUCTORS qui

contient trois champs à valeurs multiples.

Figure 7.21 Une version de la table INSTRUCTORS contenant trois champs à

valeurs multiples.

C ATÉGORIES ENSEIGNÉES —Cela indique les catégories de cours qu'un instructeur

peut enseigner.
NIVEAU M AXIMUM ENSEIGNÉ —Cela indique le niveau de compétence maximum

que l'instructeur peut enseigner pour une catégorie donnée.

LANGUES PARLÉES —Cela indique les langues étrangères qu'un instructeur

peut parler .

Votre tâche ici semble relativement claire : vous allez utiliser la procédure que

vous venez d'apprendre pour résoudre ces champs à valeurs multiples. Vous

remarquez alors un petit problème relativement obscur : il existe une association univoque

distincte entre les valeurs des CATEGORIES ENSEIGNÉES et les valeurs du NIVEAU

MAXIMUM ENSEIGNÉ pour un enregistrement donné. Vous n'auriez probablement

pas remarqué cette anomalie si vous n'aviez pas examiné attentivement les

échantillons de données.au sein de ces domaines. Ne t'inquiète pas; vous

utiliserez toujours la même procédure, mais avec une modification mineure.

Vous rencontrerez occasionnellement une situation comme celle-ci, dans

laquelle un champ donné (qu'il soit à valeur unique ou à valeurs multiples)

dépend d'un champ à valeurs multiples particulier. Vous pouvez facilement

résoudre ce problème en incluant le champ dépendant dans la structure de la

nouvelle table que vous créez pour résoudre le champ à plusieurs valeurs. La

figure 7.22 montre les résultats de la consolidation de cette technique avec la

précédente pour résoudre les C ATEGORIES ENSEIGNÉES . (Il montre également la

résolution de L ANGUAGES S POKEN .)

Figure 7.22 Résolution des champs en plusieurs parties dans la table
INSTRUCTORS.

La redondance dans les nouvelles tables est acceptable car, encore une fois,

elle est minime. Au chapitre 10 , vous apprendrez comment réduire encore

davantage ce type de redondance en reliant les tables aux clés primaires et

aux clés étrangères.

Affiner les structures des tables

Maintenant que vous avez affiné les champs et vérifié que chaque champ est

correct, vous pouvez commencer le processus d'affinement des structures de

table. Votre objectif dans cette phase du processus de conception est de vous

assurer que vous avez attribué les champs appropriés à chaque table et que

vous avez correctement défini la structure de chaque table. Ce processus

révélera également si les tables présentent des anomalies que vous devez

résoudre.

Un mot sur les données redondantes et les champs en double

Vous avez vu le terme données redondantes utilisé assez souvent dans ce

chapitre. Les données redondantes ont été qualifiées d’inacceptables dans de

nombreux cas, mais appropriées dans d’autres. Pour que vous puissiez mieux

comprendre comment déterminer quand des données redondantes sont

acceptables, une définition du terme s'impose.

Les données redondantes sont une valeur qui est répétée dans un champ en
raison de la participation du champ à la mise en relation de deux tables ou en

raison d'une anomalie dans un champ ou une table. Dans un premier temps,

les données redondantes sont appropriées ; par définition, un champ utilisé

pour relier une table à une autre contiendra des données redondantes. (Vous

en apprendrez davantage à ce sujet au chapitre 10. ) Les données redondantes

sont cependant totalement inacceptables dans le second cas, car elles posent

des problèmes de cohérence et d'intégrité des données ; par conséquent, vous

devez toujours vous efforcer de limiter les données redondantes au minimum

absolu.

Un champ en double est un champ qui apparaît dans deux tables ou plus pour

l'une de ces raisons.

• Il est utilisé pour relier un ensemble de tables entre elles.

• Il indique plusieurs occurrences d’un type particulier de valeur.

• Il existe un besoin perçu d’informations supplémentaires.

Le seul cas dans lequel un champ en double est nécessaire est lorsqu'il sert à

établir une relation entre deux tables ; il constitue le seul moyen d'associer les

enregistrements de la première table aux enregistrements de la seconde

table. Les champs en double sont inutiles dans tous les autres cas et vous

devez les éviter car ils introduisent des données inutiles et redondantes.

Au fur et à mesure que vous affinerez la structure de chaque table, vous

évaluerez s’il convient de conserver un champ en double donné dans la

table. Si la raison de son existence dans le tableau est valable, alors vous la

conserverez ; sinon, vous le supprimerez. Vous apprendrez comment gérer

efficacement les données redondantes et les champs en double inutiles dans

les sections suivantes.

Utiliser une table idéale pour affiner les structures de table

Malgré vos efforts pour affiner les champs d'une table, la structure de la table

elle-même peut contenir des anomalies qui peuvent produire des données

redondantes inutiles et rendre difficile l'utilisation des données de la

table. Vous pouvez identifier une structure de table potentiellement

problématique en déterminant si elle est conforme aux éléments de la table

idéale.

Éléments de la table idéale

Les éléments de la table idéale constituent un ensemble de lignes directrices

que vous pouvez utiliser pour créer des structures de table solides et repérer

facilement les tables mal conçues. Une structure de table idéale présente les

caractéristiques suivantes :
• Il représente un sujet unique, qui peut être un objet ou un événement. Oui,

je sais, je l'ai déjà dit plusieurs fois. Le fait est que je ne saurais trop insister

sur ce point. Tant que vous garantissez que chacune de vos tables

représente un seul sujet, vous réduisez considérablement le risque de

problèmes potentiels d’intégrité des données. Cet élément valide le travail

que vous avez effectué lors des étapes d'analyse et d'entretien du

processus de conception de la base de données, ainsi que le travail que

vous venez d'effectuer.

• Il possède une clé primaire. Ceci est important pour deux raisons : une clé

primaire identifie de manière unique chaque enregistrement dans une table

et elle joue un rôle clé (sans jeu de mots) dans l'établissement des relations

entre les tables. De plus, il possède des caractéristiques spécifiques qui

aident à mettre en œuvre et à appliquer différents niveaux d’intégrité des

données. Si vous ne parvenez pas à attribuer une clé primaire à chaque

table, vous finirez par rencontrer des problèmes d'intégrité des données. Le

chapitre 8 , « Clés », couvre les clés primaires plus en détail.

• Il ne contient pas de champs en plusieurs parties ou à valeurs

multiples. Théoriquement, vous devriez avoir résolu ces problèmes lorsque

vous avez affiné les structures de terrain. Néanmoins, c'est toujours une

bonne idée de revoir les champs une dernière fois pour vous assurer que

vous avez complètement supprimé chacun d'entre eux.

• Il ne contient pas de champs calculés. Même si vous pensez peut-être que

vos structures de table actuelles ne contiennent pas de champs calculés,

vous avez peut-être accidentellement oublié un ou deux champs calculés

lors du processus d'affinement des champs. C'est le bon moment pour revoir

les structures des tableaux et vous assurer de supprimer les champs

calculés que vous avez peut-être manqués.

• Il ne contient pas de champs en double inutiles. (Notez que cette directive

ne s'applique pas aux champs utilisés pour relier un ensemble de tables

entre elles, comme ceux utilisés dans l'exemple de la figure 7.22 .) L'une

des caractéristiques d'une table mal conçue est l'inclusion de champs en

double provenant d'autres tables. Vous pourriez vous sentir obligé d'ajouter

des champs en double à une table pour l'une des deux raisons suivantes :

fournir des informations de référence ou indiquer plusieurs occurrences d'un

type de valeur particulier. Les champs en double tels que ceux-ci soulèvent

diverses difficultés lorsque vous travaillez avec les données ou tentez

d'extraire des informations de la table.

• Il ne contient qu’un minimum absolu de données redondantes. N'oubliez pas

qu'une base de données relationnelle ne sera jamais totalement exempte de

données redondantes. Cependant, vous pouvez (et devez) vous assurer que

chaque table contient le moins de données redondantes possible.

Résolution des champs en double inutiles

Avant d'apporter les dernières modifications aux structures des tables, vous

devez d'abord supprimer tous les champs en double inutiles de la base de

données. Vous pourrez ensuite affiner les tableaux pour qu’ils soient conformes

aux Éléments du Tableau Idéal.

Les champs en double servant à fournir des informations de référence

(également appelés champs de référence ) sont inutiles et faciles à résoudre : il

vous suffit de les supprimer du tableau. Malheureusement, de nombreuses

personnes pensent qu'un tableau doit contenir tous les champs qui

apparaîtront dans les rapports qu'ils génèrent à partir de celui-ci. Ils

introduisent donc dans le tableau divers champs en double qu'ils jugent

nécessaires. Ils supposent que le tableau sera alors en mesure de fournir

toutes les informations requises pour leurs rapports. Cependant, ils se

trompent et leur action est à la fois imprudente et indésirable. Les tableaux

contenant des champs de référence sont mal conçus et présenteront un certain

nombre de problèmes, dont beaucoup deviendront de plus en plus évidents à

mesure que le processus de conception de la base de données se

déroulera. Les champs de référence obligent l'utilisateur ou le programme

d'application de base de données à garantir que les valeurs de toutes les

occurrences du champ sont mutuellement cohérentes, un processus qui

comporte un risque d'erreur élevé. La figure 7.23 montre un exemple de

tableau contenant des champs de référence.

Figure 7.23 Exemple de tableau contenant des champs de référence.
Les champs M AN P HONE et W EB S ITE de la table INSTRUMENTS sont des

champs de référence et, par définition, sont en réalité des champs en double

inutiles. Vous n'avez certainement pas besoin de les inclure dans ce tableau car

ils font déjà partie de la structure de la table MANUFACTURERS ; par

conséquent, vous pouvez les supprimer de la table INSTRUMENTS pour

résoudre le problème de duplication inutile. (M ANUFACTURER n'est pas un champ

de référence car il relie actuellement la table INSTRUMENTS à la table

MANUFACTURERS.) Vous apprendrez au chapitre 12 , « Vues », que vous

pouvez travailler avec les champs de la table INSTRUMENTS et de la table

MANUFACTURERS en même temps. temps en les combinant au sein

d’une vue (table virtuelle). Vous pouvez ensuite utiliser cette vue comme base

pour compiler les rapports dont vous avez besoin.

Les champs en double servant à indiquer plusieurs occurrences du même type

de valeur sont également inutiles. Par exemple, regardez la version du tableau

ÉTUDIANTS présentée dans la figure 7.24 .

Figure 7.24 Un exemple simple de tableau contenant des champs en double

inutiles.
I NSTRUMENT 1, I NSTRUMENT 2 et I NSTRUMENT 3 sont des champs en double qui

représentent plusieurs occurrences du même type de valeur. Leur objectif dans

le tableau est de permettre au département de musique de suivre les

instruments vérifiés par un étudiant donné. Outre les difficultés que posent ces

champs pour récupérer des informations sur un instrument particulier, ils

limitent également le nombre d'instruments qu'un étudiant peut consulter. Que

se passe-t-il si plusieurs étudiants souhaitent découvrir plus de trois

instruments ?

Ce type de structure de champ vous semble-t-il étrangement familier ? Cela

devrait! C'est similaire à celui de la figure 7.18 . Comme vous l'avez

probablement déjà deviné, ce n'est rien de plus qu'un champ à plusieurs

valeurs aplati. Attention, la personne qui a créé cette table n'avait

probablement pas en tête un champ à valeurs multiples (et la plupart des gens

qui créent des champs comme ceux-ci non plus), mais c'est vraiment ce qu'il

est.
Vous savez déjà comment gérer ces champs en double inutiles, car vous savez

comment résoudre les champs à plusieurs valeurs. Vous pouvez facilement

corriger la table STUDENTS en visualisant d'abord les champs I NSTRUMENT 1,

I NSTRUMENT 2 et I NSTRUMENT 3 comme un champ à plusieurs valeurs singulier,

puis en le résolvant comme vous le feriez pour n'importe quel champ à

plusieurs valeurs. La figure 7.25 illustrece processus. La version ombrée du

tableau ÉTUDIANTS montre comment vous visualisez les champs d'instruments

comme un champ multivalué singulier. Vous résolvez ensuite le champ à

valeurs multiples en appliquant le processus en trois étapes que vous avez

appris précédemment, ce qui produit la table ÉTUDIANTS révisée et la nouvelle

table INSTRUMENTS ÉTUDIANTS. Lorsque vous aurez terminé, vous pourrez

saisir n'importe quel nombre d'instruments pour un élève particulier. Vous

pouvez ensuite facilement récupérer des informations telles que les noms des

étudiants qui ont testé une guitare, une liste des instruments actuellement

testés par un étudiant en particulier et le nombre d'étudiants qui ont testé un

piano électrique.
Figure 7.25 Résolution d'un ensemble simple de champs en double inutiles.
Dans certains cas, une table peut contenir deux ou plusieurs ensembles de

champs en double qui représentent plusieurs occurrences du même type de

valeur. La figure 7.26 montre une version légèrement différente du tableau

ÉTUDIANTSillustré à la figure 7.24 ; cette version contient deux ensembles de

champs en double. Vous pensez peut-être à ce moment précis : « Pourquoi dit-il

qu'il y a deux ensembles de champs en double alors que j'en vois

clairement trois ? « Contrairement à ce que l'on pourrait penser,

I NSTRUMENT 1/C HECKOUT D ATE 1, par exemple, ne constitue pas un ensemble de

champs dupliqués. Bien au contraire : I NSTRUMENT 1/I NSTRUMENT 2/I NSTRUMENT 3

constituent le premier ensemble de champs en double, et

C HECKOUT D ATE 1/C HECKOUT D ATE 2/C HECKOUT D ATE 3 constituent le deuxième

ensemble de champs en double.

Figure 7.26 Exemple de table avec plusieurs ensembles de champs en

double.
Vous avez probablement réalisé que ces deux ensembles de champs en double

sont en réalité deux champs à plusieurs valeurs aplatis et que vous pouvez les

résoudre de la même manière que dans l'exemple précédent. Le seul autre

problème qui doit vous préoccuper est l’association individuelle distincte entre

un instrument et une date de paiement. Ce ne sera cependant pas un

problème, car vous avez déjà été confronté à ce type de scénario. Si vous

visualisez un champ à plusieurs valeurs appelé I NSTRUMENTS et un autre appelé

C HECKOUT D ATE , vous verrez que la structure globale du tableau est assez

similaire à celle de la figure 7.21 . (Dans cette figure , il y a une association un

à un entre les champs CATEGORIES ENSEIGNÉES et NIVEAU M AXIMUM ENSEIGNÉ .)

La figure 7.27 illustre comment corriger ce tableau. Comme auparavant, la

version ombrée du tableau ÉTUDIANTS montre comment vous visualisez les

champs d'instrument et de date de départ comme des champs à plusieurs

valeurs singuliers. Vous résolvez ensuite les champs à valeurs multiples en

appliquant le processus en trois étapes que vous avez appris précédemment,

ce qui donne la table ÉTUDIANTS révisée et la nouvelle table INSTRUMENTS

ÉTUDIANTS.
Figure 7.27 Résolution des multiples ensembles de champs en double dans la
table STUDENTS.

Maintenant que vous connaissez les éléments de la table idéale, passez en

revue les structures de votre table et affinez-les si nécessaire. Lorsque vous

avez des doutes sur un tableau particulier, dessinez sa structure sur une feuille

de papier et chargez-y des exemples de données. Vous pourrez alors résoudre

les anomalies révélées par les données.

Établir des tables de sous-ensembles

À mesure que vous affinez les structures de vos tables, vous constaterez peut-

être que certains champs d'une table particulière ne contiennent pas toujours

des valeurs. Cette situation n'affectera pas votre capacité à récupérer des

informations à partir du tableau, mais elle peut indiquer que le tableau pourrait

nécessiter un affinement supplémentaire. Considérez la structure de la table

INVENTORY dans la figure 7.28 .

Figure 7.28 Structure d'un tableau d'inventaire de bureau.

Dans ce scénario, la table contient des données sur divers éléments du bureau

d'une personne, tels que le mobilier de bureau, l'équipement de bureau

(ordinateurs, imprimantes, etc.) et les livres. Il est inévitable que les valeurs de

plusieurs champs dans de nombreux enregistrements soient vides. Par

exemple, un livre n'aura pas de FABRICANT , de MODÈLE ou de DATE

D'EXPIRATION DE LA GARANTIE , et une imprimante n'aura pas d' AUTEUR , D' ÉDITEUR ,

d' ISBN ou de C ATÉGORIE . Cela ne pose pas de problème d'un point de

vue physique (l'espace disque limité n'est certainement pas le problème

critique des années passées), mais cela peut poser un problème de

perception . Les utilisateurs (et la direction, d'ailleurs) deviennent assez

nerveux lorsqu'ils voient beaucoup de valeurs vides dans un tableau. Les

données sont-elles manquantes ? Quelqu'un a-t-il oublié de renseigner ces

champs ? Quelqu'un a-t-il supprimé les données par erreur ? L'ordinateur a-t-il

accidentellement détruit les valeurs d'origine ? (Oui, le mythe urbain

« L'ordinateur l'a fait ! » perdure toujours.) La question la plus importante est la

suivante : si vous adhériez aux éléments de la table idéale lorsque vous créiez

cette table, comment en êtes-vous arrivé à cette table ? structure particulière ?

Heureusement, il ne s’agit là que d’un autre type d’anomalie structurelle qui se

produit occasionnellement lors de la conception de différents tableaux. Votre

tâche consiste maintenant à apprendre à y faire face de manière appropriée.

La première étape consiste à déterminer si la table INVENTORY est réellement

conforme au premier élément d’une table idéale (c’est-à-dire « Elle représente

un seul sujet »). Un tableau qui contient un grand nombre de valeurs vides

dans ses champs représente généralement (mais pas toujours) plus d'un

sujet. Réfléchissez un instant aux deux ensembles de champs en question et

vous vous rendrez vite compte qu'ils représentent les caractéristiques de deux

aspects distincts du sujet du tableau. Le premier ensemble de champs décrit

l'inventaire des équipements et le deuxième ensemble de champs décrit

l'inventaire des livres ; en outre, les deux types d'inventaire partagent des

caractéristiques communes, telles que le NOM DE L'ARTICLE , la D ESCRIPTION

DE L'ARTICLE et la VALEUR ACTUELLE . Essentiellement, « Équipement » et « Livres »

sont des sujets qui dépendent de la table INVENTORY pour leur existence

même ; ni l’un ni l’autre ne décrit un objet ou un événement complètement

distinct. Par conséquent, ce sont des sujets subordonnés et vous allez créer

une table de sous-ensemble pour chacun d’eux.

Tout comme une table de données représente un sujet distinct, une table de

sous-ensemble représente un sujet subordonné d'une table de données

particulière. La table de sous-ensemble contient des champs qui sont

pertinents pour le sujet subordonné qu'elle représente, et elle comprend

également un ou plusieurs champs de la table de données qui servent à relier

la table de données à la table de sous-ensemble. Il est important de noter

qu'une table de sous-ensemble ne contient pas de champs représentant des

caractéristiques communes à elle et à la table de données ; ces champs

doivent rester dans la table de données.

Maintenant que vous avez déterminé que la table INVENTAIRE décrit trois

sujets (peu importe que deux d'entre eux soient des sujets subordonnés), vous

devez la mettre en conformité avec le premier élément d'une table idéale en

supprimant les champs en question. Vous utilisez ensuite les champs comme

base pour deux nouvelles tables de sous-ensembles, une pour chaque sujet

subordonné. Voici les étapes à suivre pour accomplir ces tâches.

1. Utilisez les champs M ANUFACTURER ,M ODEL et W ARRANTY E XPIRATION D ATE pour

créer une nouvelle table de sous-ensemble appelée EQUIPMENT.

2. Utilisez les champs P UBLISHER ,A UTHOR ,I SBN et C ATEGORY pour créer une

nouvelle table de sous-ensemble appelée BOOKS.

3. Ajoutez I TEM N AME aux deux tableaux ; ce champ reliera chaque table de

sous-ensemble à la table de données.

4. Composez une description appropriée pour les deux sous-ensembles de

tables et ajoutez-les à la liste des tables finales. Indiquez le type de chaque

table comme « Sous-ensemble ».

La figure 7.29 montre les nouvelles structures de tables de sous-ensembles.

Figure 7.29 Les nouvelles structures de table de sous-ensembles.

Prenez un moment pour revoir la structure de vos tables. Vous découvrirez

peut-être que vous avez créé des tables de sous-ensembles sans le savoir. Les

tables qui ont des structures presque identiques sont généralement des tables

de sous-ensembles ; il n'y a généralement que quelques champs uniques qui

distinguent une table de l'autre. Par exemple, considérons les deux structures

de table partielles de la figure 7.30 . Chaque tableau représente un aspect

distinct du même sujet.

Figure 7.30 Tableaux de sous-ensembles non identifiés auparavant.

Ces deux tableaux représentent des employés, mais chacun représente

un type spécifique d'employé. Notez cependant qu'il existe des champs

génériques communs aux deux tables : prénom, nom, date d'embauche,

adresse postale, ville et état. Ces champs sont inutilement dupliqués, vous

devrez donc affiner les structures des tables pour résoudre ce problème.
Affiner des tables de sous-ensembles précédemment non identifiés

Lorsque vous identifiez des tables de sous-ensembles telles que celles-ci, vous

pouvez les affiner en suivant ces étapes.

1. Supprimez tous les champs que les tables de sous-ensembles ont en

commun et utilisez-les comme base pour une nouvelle table de données .

2. Identifiez le sujet que représente la nouvelle table de données, puis donnez

à cette table un nom approprié.

3. Assurez-vous que les tables de sous-ensembles représentent des sujets

subordonnés de la table de données et modifiez les noms des tables de

sous-ensembles si nécessaire.

4. Composez une description appropriée pour le tableau de données, puis

ajoutez-la à la liste finale des tableaux. Indiquez le type de tableau comme

« Données ».

La figure 7.31 montre les résultats de l'utilisation de ces étapes sur les tables

EMPLOYÉS À TEMPS PLEIN et EMPLOYÉS À TEMPS PARTIEL.

Figure 7.31 Les résultats du raffinement des tables de sous-ensembles.

À ce stade, toutes vos structures de table devraient être en assez bon

état. Cependant, vous devrez les affiner encore davantage à mesure que vous

en apprendrez davantage sur les clés primaires, les clés étrangères, les

relations et les règles métier.

EXEMPLE : ÉTABLIR DES STRUCTURES DE TABLE

Vous allez maintenant définir la liste de tables préliminaires pour les vélos de

Mike. Comme vous le savez, la première chose que vous devez faire est de

consulter la liste préliminaire des champs pour déterminer les sujets que vous

pouvez déduire des champs de la liste. La figure 7.32 montre un

échantillon partiel de cette liste.

Figure 7.32 Liste préliminaire des vélos de Mike.

Après avoir soigneusement examiné l'intégralité de la liste de champs

préliminaire, vous déterminez que les champs de la liste suggèrent les sujets

suivants : clients, employés, factures, produits et fournisseurs. Vous compilez

ensuite ces éléments dans la première version de votre liste de tableaux

préliminaires.

Vous créez maintenant une deuxième version de la liste en fusionnant la liste

de tableaux préliminaires actuelle avec la liste de sujets que vous avez créée

au cours du processus d'analyse. Gardez les étapes suivantes à l’esprit lorsque

vous fusionnez les deux listes.

1. Résolvez les éléments qui sont dupliqués sur les deux listes. N'oubliez pas

qu'un seul élément peut apparaître sur les deux listes, tout en représentant

des sujets différents. Lorsque vous identifiez de tels éléments, utilisez les

techniques appropriées pour résoudre ce problème.

2. Résolvez les éléments qui représentent le même sujet mais portent des

noms différents. Vous voulez vous assurer qu’un seul tableau représente un

sujet particulier.

3. Combinez les éléments restants dans une seule liste. La liste combinée

devient la deuxième version de la liste des tableaux préliminaires.

Après avoir suivi ces étapes, votre liste de tables préliminaires devrait

ressembler à celle présentée dans la figure 7.33 .

Figure 7.33 La deuxième version de la liste des tableaux préliminaires.

Vous rayez « Clients », « Employés » et « Produits » sur la liste des sujets car ils

représentent les mêmes sujets que leurs homologues de la liste du tableau

préliminaire. La table VENTES n'a pas d'équivalent dans la liste des tables

préliminaires, mais elle représente le même sujet que les « Factures

». Cependant, « Factures » est plus significatif pour Mike et son équipe, vous

l'utilisez donc dans la liste des tableaux préliminaires au lieu de

« Ventes ». Une situation similaire existe entre les « Fournisseurs » et les

« Vendeurs » ; Mike sélectionne « Fournisseurs » comme nom à afficher sur la

liste du tableau préliminaire, vous rayez donc « Fournisseurs ».

Note

La sélection d'un nom qui représente le mieux le sujet du tableau est une tâche

arbitraire. Une bonne règle à suivre est d’utiliser le nom qui est le

plus significatif pour tous les membres de l’organisation.

Vous allez maintenant travailler sur la version finale de la liste des tableaux

préliminaires. Utilisez les objectifs de mission que vous avez créés au début du

processus de conception de la base de données pour déterminer s'il y a des

sujets que vous avez peut-être négligés au cours des deux procédures

précédentes. Identifiez chaque sujet représenté dans les objectifs de la mission

à l’aide de la technique d’identification du sujet. Après avoir identifié autant de

sujets que possible, vous pouvez utiliser les étapes de la deuxième procédure

pour recouper ces sujets avec les sujets actuellement répertoriés dans la liste

du tableau préliminaire. Lorsque vous avez terminé l'examen et que vous

avezrésolu les éléments en double, votre version finale de la liste des tableaux

préliminaires est complète.

Il s'avère que tous les sujets que vous avez identifiés à partir des objectifs de

mission pour Mike's Bikes apparaissent déjà sur la liste du tableau

préliminaire. C’est une bonne nouvelle car cela vous permet de réaliser votre

recoupement assez facilement. Satisfait d'avoir terminé la tâche à fond, vous

disposez désormais de la version finale de la liste des tableaux préliminaires.

Maintenant que la liste de tables préliminaires est terminée, vous êtes prêt à la

transformer en liste de tables finale. Gardez ces étapes à l’esprit lorsque vous

commencez ce processus.

1. Affinez les noms des tables. Utilisez les directives appropriées pour garantir

que chaque nom de table est clair, sans ambiguïté, descriptif et significatif.
2. Composez une description appropriée pour chaque tableau. Assurez-vous

que la description de la table définit explicitement la table et indique son

importance pour l'organisation. Utilisez les directives pertinentes pour créer

chaque description de tableau.

3. Indiquez le type de table. N'oubliez pas qu'un tableau peut être classé de

quatre manières : données, liaison, sous-ensemble ou validation. À ce stade,

toutes vos tables sont des tables de données .

La figure 7.34 montre un exemple partiel de la liste de table finale pour les

vélos de Mike.

Figure 7.34 Une liste partielle de la liste finale de la table pour les vélos de
Mike.
L'ordre du jour suivant consiste à associer les champs de la liste de champs

préliminaire à chaque table de la liste de tables finale. Assurez-vous de

sélectionner les champs qui représentent le mieux les caractéristiques du sujet

de chaque tableau ; chaque domaine doit définir ou décrire un aspect

particulier du sujet. La figure 7.35 montre un exemple partiel des structures de

table pour Mike's Bikes.

Figure 7.35 Une liste partielle des structures de table pour Mike's Bikes.

Maintenant, vous affinez les champs. N'oubliez pas de suivre ces étapes

lorsque vous travaillez avec chaque champ.

Améliorez le nom du champ. Utilisez les directives appropriées pour garantir

que chaque nom de champ est aussi clair, sans ambiguïté et descriptif que

possible.
Déterminez si le champ est conforme aux éléments du champ idéal. Assurez-

vous de vérifier les champs en plusieurs parties et à plusieurs valeurs. Comme

vous l'avez appris précédemment, ils peuvent causer un certain nombre de

problèmes au sein d'une table.

Lorsque vous examinez les champs, vous décidez d'abréger certains noms de

champs dans les tables CUSTOMERS, EMPLOYEES et INVOICES, en

raccourcissant CUSTOMER en C UST et EMPLOYEE en E MP . Vous décidez

également que le nom du champ Q UANTITY (dans la table PRODUITS) ne décrit

pas complètement la caractéristique qu'il représente, vous le remplacez donc

par Q UANTITY O N H AND . Les champs de téléphone dans les tables CUSTOMERS

et EMPLOYEES souffrent du même problème, vous les remplacez donc par

C UST H OME P HONE et E MP H OME P HONE , respectivement. De plus, vous

remplacez SSN par NUMÉRO DE SÉCURITÉ SOCIALE afin que le nom du champ soit

absolument sans ambiguïté .

Une enquête plus approfondie sur les champs révèle que presque tous sont

conformes aux éléments du champ idéal. Les seules exceptions sont les

champs d'adresse des tables CLIENTS et EMPLOYEES, ainsi que les champs

E MPLOYEE N AME des tables EMPLOYEES et FACTURES. Après avoir vérifié que

vous pouvez décomposer chaque champ d'adresse en quatre éléments

individuels (adresse, ville, état et code postal), vous transformez ces éléments

en champs et les ajoutez aux tables CLIENTS et EMPLOYÉS. De même, vous

remarquez que le champ E MPLOYEE N AME représente deux éléments (prénom et

nom) et vous apportez les ajustements appropriés à ce champ dans les tables

EMPLOYEES et FACTURES.
La figure 7.36 montre le résultat de toutes les modifications que vous avez

apportées aux champs.

Figure 7.36 Affinements apportés aux champs dans les structures de table.

Votre tâche finale consiste à affiner les structures des tables. Assurez-vous que

vous avez attribué les champs appropriés à chaque table et que vous avez

correctement défini chaque table. N'oubliez pas de suivre ces étapes lorsque

vous travaillez avec chaque tableau.

1. Résolvez les champs en double inutiles. Lorsque vous créez de nouvelles

tables suite à la résolution de champs en double, assurez-vous de les

identifier correctement et de les ajouter à la liste des tables finales.

2. Déterminez si chaque tableau est conforme aux éléments du tableau

idéal. Assurez-vous de résoudre toutes les anomalies que vous identifiez

dans les champs ou dans la structure du tableau dans son ensemble.

3. Établissez des tableaux de sous-ensembles, le cas échéant. Assurez-vous

d'identifier correctement ces tables et de les ajouter également à la liste des

tables finales.

Au fur et à mesure que vous terminez votre examen des tableaux, vous

déterminez qu'ils sont tous conformes aux éléments du tableau idéal, à

l'exception du tableau FACTURES. Le seul problème avec cette table est qu'elle

contient un champ en double inutile : C UST H OME P HONE . Vous pouvez toutefois

supprimer ce champ du tableau, car il ne fournit que des informations de

référence.

Lorsque vous travaillez avec la table PRODUCTS, vous remarquez que vous

pourrez peut-être supprimer certains champs, puis les utiliser comme base

pour une table de sous-ensemble. Vous révisez donc le tableau une fois de

plus. La figure 7.37 montre la structure de la table PRODUCTS que vous êtes en

train d'examiner. (Il s'agit d'une version étendue de la structure de table

présentée dans la figure 7.36 .)

Figure 7.37 La structure de la table PRODUCTS (version étendue).

Votre hypothèse s'avère correcte. Vous déterminez que certains champs

décrivent un service et vous pouvez interpréter un service comme étant un

type de produit différent. Un service est similaire à un produit dans la mesure

où il a un nom, une description et une catégorie, mais il est différent dans la

mesure où il a un type, des frais de matériaux, des frais de service et une date

de service. Dans cet esprit, vous créez une nouvelle table de sous-ensemble

appelée SERVICES, apportez les modifications appropriées à la table PRODUITS

et utilisez le champ P RODUCT N AME .pour relier les deux tableaux entre

eux. Vous ajoutez ensuite la liste appropriée pour la table SERVICES à la liste de

table finale. La figure 7.38 montre la table PRODUITS révisée et la nouvelle

table du sous-ensemble SERVICES.

Figure 7.38 Les nouvelles tables PRODUITS et SERVICES.

Résumé

Nous avons ouvert le chapitre par une discussion de la liste des tableaux

préliminaires. Cette liste constitue les structures de tables initiales de la

nouvelle base de données. Vous avez appris à élaborer cette liste à l'aide de la

liste de terrain préliminaire, de la liste des sujets et des objectifs de mission,

que vous avez tous compilés lors de la phase d'analyse du processus de

conception de la base de données.

Nous avons ensuite discuté de la procédure de transformation de la liste de

tables préliminaire en une liste de tables finale, qui contient le nom, le type et

la description de chaque table de la base de données. Vous avez appris un

ensemble de directives pour créer des noms de table et un autre ensemble

de directives pour composer des descriptions de table. Nous avons ensuite

travaillé sur la création de noms de tables sans ambiguïté, descriptifs et

significatifs, ainsi que de descriptions définissant explicitement les tables, tout

en indiquant leur importance pour l'organisation. Vous avez également appris

que solliciter l'aide des utilisateurs etla gestion est cruciale pour le processus

d’élaboration de descriptions de tableaux bien définies. Les descriptions des

tableaux doivent être adaptées et facilement comprises par tous les membres

de l'organisation.

Nous avons ensuite discuté du processus d'association des champs à chaque

table de la liste finale des tables. Ici, vous avez appris à créer une structure

pour une table donnée en utilisant les champs de la liste de champs

préliminaires qui représentent le mieux les caractéristiques du sujet de la table.

L'affinement des champs a été le prochain sujet de discussion et vous avez

appris un ensemble de directives pour créer des noms de champs qui vous

aideront à garantir qu'ils sont clairs, descriptifs et significatifs. Vous avez

également découvert les éléments du champ idéal. Vous savez désormais que

vous pouvez résoudre les anomalies dans un champ en déterminant s'il est

conforme à ces éléments. Nous avons ensuite discuté de la façon de résoudre

les champs multiparties et à valeurs multiples . Vous avez appris que la

décomposition de champs en plusieurs parties génère de nouveaux champs,

tandis que la décomposition de champs à valeurs multiples génère de

nouvelles tables.
Le chapitre s'est terminé par une discussion sur le raffinement des structures

de tables. Vous avez appris à identifier les éléments de la table idéale et vous

savez maintenant que vous pouvez déceler un problème de structure de table

en déterminant si une table est conforme à ces éléments. Nous avons ensuite

discuté des champs en double inutiles, et vous savez maintenant qu'ils

apparaissent dans un tableau pour l'une des deux raisons suivantes : fournir

des informations de référence ou représenter différentes occurrences du même

type de valeur. Vous avez ensuite appris à résoudre les champs en double pour

éliminer les problèmes qu'ils présentent.

La discussion finale a porté sur le thème des tableaux de sous-

ensembles. Comme vous le savez maintenant, une table de sous-ensemble

représente un sujet subordonné d'une table de données particulière, et une

relation distincte existe entre la table de sous-ensemble et la table de

données. Vous savez également que vous pouvez créer explicitement des

tables de sous-ensembles. Vous avez ensuite appris que vous avez peut-être

créé sans le savoir des tables de sous-ensembles plus tôt dans le processus de

conception de la base de données et que vous devez rechercher des tables de

sous-ensembles que vous n'avez pas identifiées auparavant. Lorsque vous

identifiez une table de sous-ensemble, vous l'affinez et l'ajoutez à la liste des

tables finales.

Questions de révision

1. Comment identifier et établir des tables pour une nouvelle base de

données ?

2. Pourquoi utilisez-vous la liste de champs préliminaire pour vous aider à

définir les tables de la base de données ?

3. Quelle action entreprenez-vous lorsqu'un élément de la liste des sujets et un

élément nommé différemment sur la liste du tableau préliminaire représentent

tous deux le même sujet ?

4. Quelles informations la liste de la table finale fournit-elle ?

5. Énoncez trois directives pour créer des noms de table.

6. Énoncez deux lignes directrices pour rédiger des descriptions de tableaux.

7. Comment attribuer des champs à une table de la liste des tables finales ?

8. Énoncez trois directives pour créer des noms de champs.

9. Quels sont les deux problèmes que des champs mal conçus peuvent

causer ?

10. Que pouvez-vous utiliser pour résoudre les anomalies sur le terrain ?

11. Énoncez trois des éléments du champ idéal.

12. Dans quelles conditions les données redondantes sont-elles acceptables ?

13. De manière générale, quelles sont les trois étapes suivez-vous pour

résoudre un champ à valeurs multiples ?

14. Quand est-il nécessaire d'utiliser un champ en double dans une table ?

15. Comment affiner les structures des tableaux ?

16. Énoncez trois des éléments de la table idéale.

17. Qu'est-ce qu'une table de sous-ensembles ?

rtd
qP
ouaeAller au contenu
sercbLes sujets
uahlCommencer à apprendre
En
em vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
èr
7. Établir des structures de table
tcd8. Clés
rhe 9. Spécifications du terrain
es
7h 49min restantes
s
m
a
t
i
è
r
e
s

Clés

Un fait en soi n'est rien. Elle ne vaut que par l'idée qui s'y rattache, ou par la
preuve qu'elle fournit.

-CLAUDE BERNARD __

Sujets abordés dans ce chapitre

Pourquoi les clés sont importantes

Établir des clés pour chaque table

Intégrité au niveau de la table

Révision des structures de table initiales

Exemple : établissement de clés

Résumé

Questions de révision

À présent, vous avez identifié tous les sujets que la base de données suivra et

défini les structures de tableaux qui représenteront ces sujets. De plus, vous

avez soumis les structures à un processus de sélection pour contrôler leur

composition et leur qualité. Dans cette étape suivante du processus de

conception de base de données, vous commencerez à attribuer des clés à

chaque table. Vous apprendrez bientôt qu'il existe différents types de clés et

que chacune joue un rôle particulier dans la structure de la base de

données. Toutes les clés sauf une sont attribuées au cours de cette

étape ; vous attribuerez la clé restante plus tard (au Chapitre 10 , « Relations

entre les tables ») au fur et à mesure que vous établirez des relations entre les

tables.

Pourquoi les clés sont importantes

Les clés sont essentielles à la structure d'une table pour les raisons suivantes :

• Ils garantissent que chaque enregistrement d'une table est précisément

identifié. Comme vous le savez déjà, un tableau représente une collection

singulière d’objets ou d’événements similaires. (Par exemple, une table

CLASSES représente une collection de classes, pas seulement une classe

unique.) L'ensemble complet des enregistrements de la table constitue la

collection, et chaque enregistrement représente une instance unique du

sujet de la table au sein de cette collection. Vous devez disposer d'un

moyen d'identifier avec précision chaque instance, et une clé est le

dispositif qui vous permet de le faire.

• Ils aident à établir et à faire respecter divers types d’intégrité. Les clés sont

un élément majeur de l’intégrité au niveau de la table et de l’intégrité au

niveau des relations. Par exemple, ils vous permettent de vous assurer

qu'une table possède des enregistrements uniques et que les champs que

vous utilisez pour établir une relation entre une paire de tables contiennent

toujours des valeurs correspondantes.

• Ils servent à établir des relations entre les tables. Comme vous l'apprendrez

au chapitre 10 , vous utiliserez des clés pour établir une relation entre une

paire de tables.

Assurez-vous toujours de définir les clés appropriées pour chaque table. Cela

vous aidera à garantir que les structures des tables sont solides, que les

données redondantes dans chaque table sont minimes et que les relations

entre les tables sont solides.

Établir des clés pour chaque table

Votre prochaine tâche consiste à établir des clés pour chaque table de la base

de données. Les quatre principaux types de clés sont les clés candidates,

primaires, étrangères et non-clés. Le type d'une clé détermine sa fonction dans

la table.

Clés des candidats

Le premier type de clé que vous établissez pour une table est la clé candidate ,

qui est un champ ou un ensemble de champs qui identifie de manière unique

une instance unique (un enregistrement dans la table) du sujet de la

table. Chaque table doit avoir au moins une clé candidate. Vous finirez par

examiner le pool de clés candidates disponibles de la table et désignerez l’une

d’entre elles comme clé primaire officielle de la table.

Avant de pouvoir désigner un champ comme clé candidate, vous devez vous

assurer qu'il est conforme à tous les éléments d'une clé candidate. Ces

éléments constituent un ensemble de lignes directrices que vous pouvez

utiliser pour déterminer si le champ est apte à servir de clé candidate. Vous ne

pouvez pas désigner un champ comme clé candidate s’il n’est pas conforme

à l’un de ces éléments.

Éléments d'une clé de candidat

• Il ne peut pas s'agir d'un champ en plusieurs parties. Vous avez vu les

problèmes avec les champs en plusieurs parties, vous savez donc qu'en

utiliser un comme identifiant est une mauvaise idée.

• Il doit contenir des valeurs uniques. Cet élément vous aide à vous prémunir

contre la duplication d'un enregistrement donné dans la table. Les

enregistrements en double sont tout aussi mauvais que les champs en

double, et vous devez les éviter à tout prix.

• Il ne peut pas contenir de valeurs nulles. Une valeur Null représente

l'absence de valeur, et il n'y a absolument aucun moyen pour un champ clé

candidat d'identifier un enregistrement donné s'il est Null.

• Sa valeur ne peut pas entraîner une violation des règles de sécurité ou de

confidentialité de l'organisation. Les valeurs telles que les mots de passe et

les numéros de sécurité sociale ne peuvent pas être utilisées comme clé

candidate.

• Sa valeur n'est pas facultative en tout ou en partie. Une valeur facultative

implique qu’elle peut être nulle à un moment donné. Vous pouvez alors en

déduire,qu'une valeur facultative viole automatiquement l'élément

précédent et est donc inacceptable. (Cette mise en garde s'applique

particulièrement lorsque vous souhaitez utiliser deux champs ou plus

comme clé candidate.)

• Il comprend un nombre minimum de champs nécessaires pour définir

l'unicité. Vous pouvez utiliser une combinaison de champs (traités comme

une seule unité) pour servir de clé candidate, à condition que chaque champ

contribue à définir une valeur unique. Essayez toutefois d'utiliser le moins

de champs possible, car des clés candidates trop complexes peuvent

finalement s'avérer difficiles à utiliser et à comprendre.

• Ses valeurs doivent identifier de manière unique et exclusive chaque

enregistrement de la table. Cet élément vous aide à vous prémunir contre

les enregistrements en double et garantit que vous pouvez référencer avec

précision n'importe quel enregistrement de la table à partir d'autres tables

de la base de données.

• Sa valeur doit identifier exclusivement la valeur de chaque champ au sein

d'un enregistrement donné. Cet élément garantit que les clés candidates de
la table constituent le seul moyen d'identifier chaque valeur de champ dans

l'enregistrement. (Vous en apprendrez plus sur cet élément particulier dans

la section sur les clés primaires.)

• Sa valeur ne peut être modifiée que dans des cas rares ou extrêmes. Vous

ne devez jamais modifier la valeur d’une clé candidate, sauf si vous avez

une raison absolue et impérieuse de le faire. Un champ aura probablement

du mal à se conformer aux éléments précédents si vous pouvez modifier sa

valeur arbitrairement.

L'établissement d'une clé candidate pour une table est assez simple :

recherchez un champ ou un ensemble de champs conforme à tous les éléments

d'une clé candidate. Vous pourrez probablement définir plusieurs clés

candidates pour une table donnée. Le chargement d'un tableau avec des

exemples de données vous donnera les moyens d'identifier avec précision les

clés candidates potentielles. (Vous avez utilisé cette même technique dans le

chapitre précédent.)
Voyez si vous pouvez identifier des clés candidates pour la table de la figure

8.1 .

Figure 8.1 Y a-t-il des clés candidates dans ce tableau ?

Vous avez probablement

identifié l' ID D' EMPLOYÉ , le NUMÉRO DE SÉCURITÉ SOCIALE , le NOM DE FAMILLE EMP ,

le PRÉNOM et NOM DE FAMILLE EMP , le CODE

POSTAL EMP et le TÉLÉPHONE HOME EMP comme candidats potentiels . clés. Mais vous

devrez examiner ces champs de plus près pour déterminer lesquels sont

réellement éligibles pour devenir des clés candidates. N'oubliez pas que vous

devez automatiquement ignorer tout champ qui ne respecte pas ne serait-ce

qu'un des éléments d'une clé de candidat.

Après un examen attentif, vous pouvez tirer les conclusions suivantes :

• L' ID D' EMPLOYÉ est éligible . Ce champ est conforme à chaque élément
d'une clé candidate.
• Le NUMÉRO DE SÉCURITÉ SOCIALE n'est pas éligible car il pourrait contenir des
valeurs nulles et compromettrait très probablement les règles de
confidentialité de l'organisation . Contrairement à ce que montrent les
exemples de données, ce champ pourrait contenir une valeur nulle. Par

exemple, de nombreuses personnes travaillant aux États-Unis n’ont pas de

numéro de sécurité sociale parce qu’elles sont citoyens d’autres pays ou

parce qu’elles sont simplement ici avec un visa de travail.

Note

Malgré son utilisation répandue dans de nombreux types de bases de données,

je vous recommande fortement de vous abstenir d'utiliser

le NUMÉRO DE SÉCURITÉ SOCIALE comme clé candidate (ou comme clé primaire,

d'ailleurs) dans aucune de vos structures de base de données.

Le site Web de la Social Security Administration détaille l'historique du numéro

de sécurité sociale et fournit des faits très intéressants sur les numéros de

sécurité sociale et le vol d'identité, qui est devenu beaucoup plus

problématique ces dernières années. Vous pouvez accéder à ces informations

intéressantes sur www.ssa.gov/policy/docs/ssb/v69n2/v69n2p55.html . Vous

pouvez trouver des informations relatives au vol d’identité dans la section

intitulée « Utilisations croissantes du SSN ».

• E MP L AST N AME n'est pas éligible car il peut contenir des valeurs en
double. Comme vous l'avez appris, les valeurs d'une clé candidate doivent
être uniques. Dans ce cas, il peut y avoir plusieurs occurrences d’un nom de

famille particulier.
• E MP PRENOM et E MP LAST NOM sont éligibles . _ _ _ Les valeurs combinées

des deux champs fourniront un identifiant unique pour un enregistrement

donné. Même si plusieurs occurrences d'un prénom ou d'un nom de famille

particulier peuvent se produire, la combinaison d'un prénom et d'un nom de

famille donnés sera toujours unique. (Certains d'entre vous disent

probablement : « Ce n'est pas nécessairement toujours vrai. » Vous avez

tout à fait raison. Ne vous inquiétez pas ; nous aborderons cette question

sous peu.)

• E MP Z IPCODE n'est pas éligible car il peut contenir des valeurs en double. De
nombreuses personnes vivent dans la même zone de code postal, donc les

valeurs dans E MP Z IPCODE ne peuvent pas être uniques.

• E MP H OME P HONE n'est pas éligible car il peut contenir des valeurs en
double et est sujet à changement. Ce champ contiendra des valeurs en
double pour l'une de ces raisons :

1. Un ou plusieurs membres de la famille travaillent pour l'organisation.

2. Une ou plusieurs personnes partagent une résidence contenant une seule

ligne téléphonique.

3. Cela pourrait être nul.

Vous pouvez affirmer en toute confiance que la table EMPLOYEES comporte

deux clés candidates : E MPLOYEE ID et la combinaison de E MP FIRST N AME et

E MP L AST N AME .

Marquez les clés candidates dans vos structures de tableaux en écrivant les

lettres « CK » à côté du nom de chaque champ que vous désignez comme clé

candidate. Une clé candidate composée de deux champs ou plus est

appelée clé candidate composite, et vous écrirez « CCK » à côté des noms des

champs qui composent la clé. Lorsque vous disposez de deux clés candidates

composites ou plus, utilisez un numéro dans la marque pour les distinguer les

unes des autres. Si vous aviez deux clés candidates composites, par exemple,

vous marqueriez l’une comme « CCK1 » et l’autre comme « CCK2 ».

Appliquez cette technique aux clés candidates pour la table EMPLOYEES de la

figure 8.1 . La figure 8.2 montre à quoi devrait ressembler votre structure une

fois cette tâche terminée.

Figure 8.2 Marquage des clés candidates dans la structure du tableau

EMPLOYEES.

Essayez maintenant d'identifier autant de clés candidates que possible pour la

table PARTS de la figure 8.3 .

Figure 8.3 Pouvez-vous identifier des clés candidates dans la table PARTS ?

À première vue, vous pourriez croire que le NOM DE LA PIÈCE ,

le NUMÉRO DE MODÈLE , la combinaison du NOM DE LA PIÈCE et du NUMÉRO DE MODÈLE et

la combinaison du NOM DU FABRICANT et du NOM DE LA PIÈCE sont des clés candidates

potentielles. Cependant, après avoir étudié cette théorie, vous arrivez aux

résultats suivants :

• P ART N AME n'est pas éligible car il peut contenir des valeurs en double. Un
nom de pièce donné sera dupliqué lorsque la pièce est fabriquée en

plusieurs modèles. C’est par exemple le cas des leviers de frein Faust.

• Le NUMÉRO DE MODÈLE n'est pas éligible car il peut contenir des valeurs
nulles. Une valeur de clé candidate doit exister pour chaque enregistrement
de la table. Comme vous pouvez le constater, certaines pièces n'ont pas de

numéro de modèle.

• P ART N AME et M ODEL NUMBER ne sont pas éligibles car l'un ou l'autre
champ peut contenir des valeurs nulles . Le simple fait que
M ODEL N UMBER puisse contenir des valeurs nulles disqualifie instantanément

cette combinaison de champs.

• NOM DU FABRICANT et NOM DE LA PIÈCE ne sont pas éligibles car les valeurs de
ces champs semblent facultatives . Rappelez-vous qu’une valeur de clé
candidate ne peut pas être facultative en tout ou en partie. Dans ce cas,

vous pouvez en déduire que la saisie du nom du fabricant est facultative

lorsqu'il apparaît en tant que composant du nom de la pièce ; par

conséquent, vous ne pouvez pas désigner cette combinaison de champs

comme clé candidate.

Il est évident que vous ne disposez pas d’un seul champ ou ensemble de

champs pouvant être qualifié de clé candidate pour la table PARTS. C'est un

problème car chaque table doit avoir au moins une clé

candidate. Heureusement, une solution existe.

Clés candidates artificielles

Lorsque vous déterminez qu'une table ne contient pas de clé candidate, vous

pouvez créer et utiliser une clé candidate artificielle (ou de substitution ). (C'est

artificiel dans le sens où cela n'est pas apparu « naturellement » dans le

tableau ; vous devez le fabriquer.) Vous établissez une clé candidate artificielle

en créant un nouveau champ conforme à tous les éléments d'une clé

candidate, puis en ajoutant à table ; ce champ devient la clé officielle du

candidat.

Vous pouvez maintenant résoudre le problème dans le tableau PARTS. Créez

une clé candidate artificielle appelée P ART N UMBER et attribuez-la à la table. (Le

nouveau champ sera automatiquement conforme aux éléments d'une clé

candidate car vous le créez à partir de zéro.) La figure 8.4 montre la structure

révisée de la table PARTS.

Figure 8.4 La table PARTS avec la clé candidate artificielle P ART N UMBER .

Lorsque vous avez établi une clé candidate artificielle pour une table, marquez

le nom du champ avec un « CK » dans la structure de la table, comme vous

l'avez fait pour la table EMPLOYEES dans l'exemple précédent.

Vous pouvez également choisir de créer une clé candidate artificielle lorsqu'elle

serait une clé candidate plus forte (et donc plus appropriée) que n'importe

laquelle des clés candidates existantes. Supposons que vous travaillez sur une table

EMPLOYEES et que vous déterminez que la seule clé candidate disponible est la

combinaison des champs E MP FIRST N AME et E MP L AST N AME . Bien qu'il puisse

s'agir d'une clé candidate valide, l'utilisation d'une clé candidate à champ

unique peut s'avérer plus efficace et permettre d'identifier plus facilement le

sujet de la table. Disons que tout le monde dans l'organisation est habitué à

utiliser un numéro d'identification unique plutôt qu'un nom comme moyen

d'identification d'un employé. Dans ce cas, vous pouvez choisir de créer un

nouveau champ nommé E MPLOYEE ID et de l'utiliser comme clé de candidat

artificielle. Il s'agit d'une pratique tout à fait acceptable : faites-le sans

hésitation ni réserve si vous pensez que cela est approprié.

 Note

Je crée généralement un champ d'identification (tel que ID D' EMPLOYÉ , ID

DE VENDEUR , ID DE DÉPARTEMENT , ID DE C ATÉGORIE , etc.) et je l'utilise comme clé de

candidat artificielle. Elle est toujours conforme aux éléments d'une clé

candidate, constitue une excellente clé primaire (éventuellement) et, comme

vous le verrez au chapitre 10 , facilite grandement le processus

d'établissement des relations entre les tables.

Passez en revue les clés candidates que vous avez sélectionnées et assurez-

vous qu'elles sont parfaitement conformes aux éléments d'une clé

candidate. Ne soyez pas surpris si vous découvrez que l'un d'entre eux n'est

pas une clé candidate après tout : une identification incorrecte d'un champ

comme clé candidate arrive occasionnellement. Lorsque cela se produit,

supprimez simplement l’indicateur « CK » du nom du champ dans la structure

de la table. La suppression d'une clé candidate ne posera pas de problème tant

que la table contient plusieurs clés candidates. Toutefois, si vous découvrez

que la seule clé candidate que vous avez identifiée pour la table n'est pas une

clé candidate, vous devez établir une clé candidate artificielle pour la

table. Après avoir défini la nouvelle clé candidate, pensez à marquer son nom

avec un « CK » dans la structure du tableau.

Clés primaires

À présent, vous avez établi toutes les clés candidates qui semblent appropriées

pour chaque table. Votre tâche suivante consiste à établir une clé primaire pour

chaque table, qui est la clé la plus importante de toutes.

• Un champ de clé primaire identifie exclusivement la table dans la structure

de la base de données et permet d'établir des relations avec d'autres

tables. (Vous en apprendrez davantage à ce sujet au chapitre 10. )

• Une valeur de clé primaire identifie de manière unique un enregistrement

donné dans une table et représente exclusivement cet enregistrement dans

l'ensemble de la base de données. Cela permet également de se prémunir

contre les enregistrements en double.

Une clé primaire doit être conforme exactement aux mêmes éléments qu’une

clé candidate. Cette exigence est facile à remplir car vous sélectionnez une clé

primaire dans le pool de clés candidates disponibles d'une table. Le processus

de sélection d'une clé primaire est quelque peu similaire à celui d'une élection

présidentielle. Tous les quatre ans, plusieurs personnes se présentent au poste

de président des États-Unis. Ces personnes sont appelées « candidats » et

possèdent toutes les qualifications requises pour devenir président. Une

élection nationale a lieu et une seule personne parmi le groupe de candidats

présidentiels disponibles est élue comme président officiel du pays. De même,

vous identifiez chaque clé de candidat qualifié dans la table, organisez votre

propre élection et sélectionnez l'une d'entre elles pour devenir la clé primaire

officielle de la table. Vous avez déjà identifié les candidats, c'est donc

maintenant l'heure des élections !

En supposant qu'il n'y ait pas d'autre préférence marginale, voici quelques

lignes directrices que vous pouvez utiliser pour sélectionner une clé primaire

appropriée.

1. Si vous disposez d’une clé candidate simple (à champ unique) et d’une clé

candidate composite, choisissez la clé candidate simple. Il est toujours

préférable d'utiliser une clé candidate contenant le moins de champs

possible.
2. Choisissez une clé candidate qui intègre une partie du nom de la table dans

son propre nom. Par exemple, une clé candidate portant un nom tel que
S ALES I NVOICE N UMBER est un bon choix pour la table SALES INVOICES.

Examinez les clés candidates et choisissez-en une qui servira de clé primaire

pour la table. Le choix est largement arbitraire : vous pouvez choisir celui qui,

selon vous, identifie le plus précisément le sujet du tableau ou celui qui est le

plus significatif pour tous les membres de l'organisation. Par exemple,

considérons à nouveau la table EMPLOYEES dans la figure 8.5 .

Figure 8.5 Quelle clé candidate doit devenir la clé primaire de la table
EMPLOYEES ?
L'une ou l'autre des clés candidates que vous avez identifiées dans le tableau

peut servir de clé primaire. Vous pouvez décider de choisir l'ID EMPLOYÉ si tout

le monde dans l'organisation est habitué à utiliser ce numéro comme moyen

d'identifier les employés dans des éléments tels que les formulaires fiscaux et

les programmes d'avantages sociaux des employés. La clé candidate que vous

choisissez finalement devient la clé primaire de la table et est régie par les

éléments d'une clé primaire. Ces éléments sont exactement les mêmes que

ceux du candidatclé, et vous devez les appliquer à la lettre. Par souci de clarté,

voici les éléments d’une clé primaire :

Éléments d'une clé primaire

• Il ne peut pas s'agir d'un champ en plusieurs parties.

• Il doit contenir des valeurs uniques.

• Il ne peut pas contenir de valeurs nulles.

• Sa valeur ne peut pas entraîner une violation des règles de sécurité ou de

confidentialité de l'organisation.

• Sa valeur n'est pas facultative en tout ou en partie.

• Il comprend un nombre minimum de champs nécessaires pour définir

l'unicité.

• Ses valeurs doivent identifier de manière unique et exclusive chaque

enregistrement de la table.

• Sa valeur doit identifier exclusivement la valeur de chaque champ au sein

d'un enregistrement donné.

• Sa valeur ne peut être modifiée que dans des cas rares ou extrêmes.

Avant de finaliser votre sélection de clé primaire, il est impératif de vous

assurer absolument que la clé primaire respecte parfaitement cet élément

particulier :

Sa valeur doit identifier exclusivement la valeur de chaque champ au sein d'un

enregistrement donné.
Chaque valeur de champ dans un enregistrement donné doit être unique dans

l'ensemble de la base de données (sauf si elle participe à l'établissement d'une

relation entre une paire de tables) et ne doit avoir qu'un seul moyen

d'identification exclusif : la valeur de clé primaire spécifique pour cet

enregistrement.

Vous pouvez déterminer si une clé primaire est entièrement conforme à cet

élément en suivant ces étapes :

1. Chargez la table avec des exemples de données.

2. Sélectionnez un enregistrement à des fins de test et notez la valeur actuelle

de la clé primaire.

3. Examinez la valeur du premier champ (celui immédiatement après la clé

primaire) et posez-vous cette question :

Cette valeur de clé primaire identifie-t-elle exclusivement la valeur actuelle

de <fieldname> ?

1. Si la réponse est « oui », passez au champ suivant et répétez la question.

2. Si la réponse est « non », supprimez le champ du tableau, passez au

champ suivant et répétez la question.

4. Continuez cette procédure jusqu'à ce que vous ayez examiné chaque valeur

de champ de l'enregistrement.

Une valeur de champ que la clé primaire n'identifie pas exclusivement indique

que le champ lui-même n'est pas nécessaire à la structure de la table ; par

conséquent, vous devez supprimer le champ et reconfirmer que le tableau est

conforme aux éléments du tableau idéal. Vous pouvez ensuite ajouter le champ

que vous venez de supprimer à une autre structure de table, le cas échéant, ou

vous pouvez le supprimer complètement car il est vraiment inutile.

Voici un exemple de la manière dont vous pouvez appliquer cette technique à

la structure de table partielle de la figure 8.6 . (Notez que I NVOICE N UMBER est la

clé primaire de la table.)

Figure 8.6 La clé primaire identifie-t-elle exclusivement la valeur de chaque

champ de cette table ?

Tout d’abord, vous chargez la table avec des exemples de données. Vous

sélectionnez ensuite un enregistrement à des fins de test (nous utiliserons le

troisième enregistrement pour cet exemple) et notez la valeur de la clé

primaire (13002). Maintenant, posez les questions suivantes pour chaque

valeur de champ de l'enregistrement.

Cette valeur de clé primaire identifie-t-elle exclusivement la valeur actuelle

de. . .

DATE DE FACTURE ? _ Oui. Ce numéro de facture identifiera toujours la date

spécifique à laquelle la facture a été créée.

PRÉNOM DU CLIENT ? _ _ _ Oui. Ce numéro de facture identifiera toujours le

prénom spécifique du client particulier qui a effectué cet achat.

C UST NOM DE FAMILLE ? _ Oui. Ce numéro de facture identifiera toujours le nom

de famille spécifique du client particulier qui a effectué cet achat.

E MP PRÉNOM ? _ _ _ Oui. Ce numéro de facture identifiera toujours le prénom

spécifique de l'employé particulier qui a servi le client pour cette vente.

E MP NOM DE FAMILLE ? _ Oui. Ce numéro de facture identifiera toujours le nom de

famille spécifique de l'employé particulier qui a servi le client pour cette vente.

E MP TÉLÉPHONE MAISON ? _ _ Non, ce n'est pas le cas ! Le numéro de

facture identifie indirectement le numéro de téléphone du domicile de

l'employé via le nom de l'employé.En fait, c'est la valeur actuelle de

E MP FIRST N AME et E MP LAST N AME qui identifie exclusivement la valeur de

E MP H OME P HONE — changez le nom de l'employé, et vous devez également

changer le numéro de téléphone . . Vous devez maintenant supprimer

E MP H OME P HONE du tableau pour deux raisons : la clé primaire n'identifie pas

exclusivement sa valeur actuelle et (comme vous l'avez probablement déjà

constaté) il s'agit d'un champ inutile. Il s'avère que vous pouvez supprimer

complètement ce champ car il fait déjà partie de la structure de la table

EMPLOYEES.

Après avoir supprimé les champs inutiles que vous avez identifiés lors de ce

test, examinez la structure du tableau révisé et assurez-vous qu'elle est

conforme aux éléments du tableau idéal.

La clé primaire doit désormais identifier exclusivement les valeurs des champs

restants de la table. Cela signifie que la clé primaire est vraiment saine et que

vous pouvez la désigner comme clé primaire officielle de la table. Supprimez le

« CK » à côté du nom du champ dans la structure du tableau et remplacez-le

par un « PK ». (Une clé primaire composée de deux champs ou plus est

appelée clé primaire composite et vous la marquez avec les lettres « CPK ».) La

figure 8.7 montre la structure révisée de la table FACTURES DE VENTES avec

le NUMÉRO DE FACTURE comme clé primaire. .

Figure 8.7 La table SALES INVOICES révisée avec sa nouvelle clé primaire.

Règles d'établissement d'une clé primaire

Lorsque vous créez une clé primaire pour chaque table de la base de données,

gardez ces deux règles à l'esprit :

1. Chaque table doit avoir une (et une seule) clé primaire. La clé

primaire devant être conforme à chacun des éléments qui la régissent, une

seule clé primaire est nécessaire pour une table particulière.

2. Chaque clé primaire de la base de données doit être unique : deux tables ne

doivent pas avoir la même clé primaire, sauf si elles entretiennent une
relation un-à-un ou si l'une d'entre elles est une table de sous-
ensemble. Vous avez appris au début de cette section que la clé primaire
identifie exclusivement une table dans la structure de la base de

données ; par conséquent, chaque table doit avoir sa propre clé

primaire unique pour éviter toute confusion ou ambiguïté possible

concernant l'identité de la table. Une table de sous-ensemble est exclue de

cette règle car elle représente une version plus spécifique du sujet d'une

table de données particulière : les deux tables doivent partager la même clé

primaire.

Plus tard dans le processus de conception de base de données, vous

apprendrez à utiliser la clé primaire pour établir une relation entre une paire de

tables.
Clés alternatives

Maintenant que vous avez sélectionné une clé candidate pour servir de clé

primaire pour une table particulière, vous allez désigner les clés candidates

restantes comme clés alternatives . Ces clés peuvent vous être utiles dans un

programme SGBDR car elles fournissent un moyen alternatif d'identifier de

manière unique un enregistrement particulier dans la table. Si vous choisissez

d'utiliser une clé alternative de cette manière, marquez son nom avec « AK »

ou « CAK » (clé alternative composite) dans la structure du tableau ; sinon,

supprimez sa désignation en tant que clé alternative et remettez-la simplement

au statut de champ normal. Vous ne vous soucierez pas des clés alternatives

pour le reste du processus de conception de la base de données, mais vous

travaillerez à nouveau avec elles.lorsque vous implémentez la base de données

dans un programme SGBDR. (La mise en œuvre et l'utilisation de clés

alternatives dans les programmes SGBDR dépassent la portée de ce travail ;

notre seul objectif ici est de les désigner comme appropriées. Ceci est

conforme à l'objectif du livre, qui est la conception logique d'une base de

données.)

La figure 8.8 montre la structure finale de la table EMPLOYEES avec la

désignation appropriée pour la clé primaire et les clés alternatives.

Figure 8.8 La table EMPLOYEES avec les clés primaires et secondaires
désignées.

Non-clés

Une non-clé est un champ qui ne sert pas de clé candidate, primaire,

alternative ou étrangère . Son seul objectif est de représenter une

caractéristique du sujet de la table et sa valeur est déterminée par la clé

primaire. Il n'y a pas de désignation particulière pour une non-clé, vous n'avez

donc pas besoin de la marquer dans la structure du tableau.

Intégrité au niveau de la table

L'intégrité au niveau des tables est un élément majeur de l'intégrité globale

des données et garantit les éléments suivants :

• Il n'y a pas d'enregistrements en double dans une table.

• La clé primaire identifie exclusivement chaque enregistrement d'une table.

• Chaque valeur de clé primaire est unique.

• Les valeurs de clé primaire ne sont pas nulles.

Vous avez commencé à établir l'intégrité au niveau des tables lorsque vous

avez défini une clé primaire pour chaque table et assuré son application en

vous assurant absolument que chaque clé primaire était entièrement conforme

aux éléments d'une clé primaire. Dans le chapitre suivant, vous améliorerez

davantage l'intégrité de la table en établissant les spécifications de

champ pour chaque champ de la table.

Révision des structures de table initiales

Maintenant que les définitions fondamentales des tableaux sont terminées,

vous devez mener des entretiens avec les utilisateurs et la direction pour revoir

le travail que vous avez effectué jusqu'à présent. Cette série d’entretiens est

assez simple et devrait être relativement facile à mener.

Lors de ces entretiens, vous accomplirez ces tâches :

• Assurez-vous que les sujets appropriés sont représentés dans la base de

données. Même s'il est très peu probable qu'un sujet important manque à
ce stade du processus de conception de la base de données, cela peut

arriver. Lorsque cela se produit, identifiez le sujet, utilisez les techniques

appropriées pour le transformer en tableau et développez-le au même degré

que les autres tableaux de la base de données.

• Assurez-vous que les noms et les descriptions des tables sont adaptés et

significatifs pour tout le monde. Lorsqu'un nom ou une description semble

prêter à confusion ou ambiguë à plusieurs personnes de l'organisation,

travaillez avec elles pour clarifier l'élément autant que possible. Il est

courant que certains noms et descriptions de tables s'améliorent au cours

du processus d'entretien.

• Assurez-vous que les noms de champs sont appropriés et significatifs pour

tout le monde. La sélection des noms de champs génère généralement de

nombreuses discussions, en particulier lorsqu'une base de données

existante est en place. Vous trouverez généralement des personnes qui font

habituellement référence à un champ particulier par un certain nom, car «

c'est ainsi qu'il s'appelle sur mon écran ». Lorsque vous modifiez le nom

d'un champ (vous avez de bonnes raisons de le faire), vous devez expliquer

diplomatiquement à ces personnes que vous avez renommé le champ afin

qu'il soit conforme aux normes imposées par la nouvelle base de

données. Vous pouvez également leur indiquer que le champ peut

apparaître avec un nom plus familier une fois la base de données

implémentée dans un programme SGBDR. Ce que vous dites est vrai ; de

nombreux SGBDR vous permettent d'utiliser un nom pour la définition

physique du champ et un autre nom à des fins d'affichage. Cependant, cette

fonctionnalité ne modifie, ne réduit ou n'annule pas la nécessité de suivre

les instructions de création de noms de champs que vous avez apprises

au chapitre 7 , « Établir des structures de table ».

• Vérifiez que tous les champs appropriés sont affectés à chaque table. C'est

votre meilleure occasion de vous assurer que toutes les caractéristiques

nécessaires relatives au sujet du tableau sont en place. Vous découvrirez

souvent que vous avez accidentellement oublié une ou deux

caractéristiques plus tôt dans le processus de conception. Lorsque cela se

produit, identifiez les caractéristiques, utilisez les techniques appropriées

pour les transformer en champs et suivez toutes les étapes nécessaires pour

les ajouter au tableau.

Une fois les entretiens terminés, vous passerez à la phase suivante du

processus de conception de la base de données et établirez les spécifications

de champ pour chaque champ de la base de données.

EXEMPLE : ÉTABLISSEMENT DE CLÉS

Il est maintenant temps d'établir des clés pour chaque table de la base de

données Mike's Bikes. Comme vous le savez, votre première tâche consiste à

établir des clés de candidat pour chaque table. Supposons que vous décidiez

de commencer par la table CUSTOMERS de la figure 8.9 .

Figure 8.9 Structure de la table CUSTOMERS dans la base de données Mike's
Bikes.

Lorsque vous examinez chaque champ, vous essayez de déterminer s'il est

conforme aux éléments d'une clé de candidat. Vous déterminez que S TATUS ,

C UST H OME T HONE et la combinaison de C UST FIRST N AME et C UST L AST N AME

sont des clés candidates potentielles, mais vous n'êtes pas sûr que l'une d'entre elles soit

entièrement conforme à tous les éléments. Vous décidez donc de tester les clés

en chargeant la table avec des exemples de données, comme le montre

la figure 8.10 .
Figure 8.10 Test des clés candidates dans la table CUSTOMERS.

N'oubliez jamais qu'un champ doit être conforme à tous les éléments d'une clé

candidate pour être considéré comme une clé candidate. Vous devez

immédiatement disqualifier le champ s'il ne remplit pas cette condition.

En examinant le tableau, vous tirez ces conclusions :

• S TATUS n'est pas éligible car il contiendra probablement des valeurs en

double. À mesure que l'entreprise se développe, Mike aura de nombreux

clients « précieux ».

• C UST H OME P HONE n'est pas éligible car il contiendra probablement des

valeurs en double et est susceptible de changer à mesure que les gens

s'éloignent des lignes fixes et migrent vers les smartphones. Les données

échantillonnées révèlent que deux clients peuvent vivre dans la même

résidence et avoir le même numéro de téléphone.

• C UST FIRST N AME et C UST L AST N AME ne sont pas éligibles car ils

contiendront probablement des valeurs en double . Les exemples de

données révèlent que la combinaison du prénom et du nom peut

représenter plusieurs clients distincts.

Ces résultats vous convainquent d’établir une clé candidate artificielle pour

cette table. Vous créez ensuite un champ appelé ID CLIENT , confirmez qu'il est

conforme aux exigences d'une clé candidate et ajoutez le nouveau champ à la

structure de la table avec la désignation appropriée.

La figure 8.11 montre la structure révisée de la table CLIENTS.

Figure 8.11 La table CUSTOMERS avec la nouvelle clé candidate artificielle,

C USTOMER ID.

Vous allez maintenant répéter cette procédure pour chaque table de la base de

données. N'oubliez pas de vous assurer que chaque table possède au

moins une clé candidate.

La prochaine étape consiste à établir une clé primaire pour chaque

table. Comme vous le savez, vous sélectionnez la clé primaire d'une table

particulière dans le pool de clés candidates disponibles de la table. Voici

quelques points à garder à l’esprit lorsque vous choisissez une clé primaire

pour une table comportant plusieurs clés candidates :

• Choisissez une clé candidate simple (à champ unique) plutôt qu’une clé

candidate composite.

• Si possible, choisissez une clé candidate dont le nom de la table est

incorporé dans son propre nom.

• Sélectionnez la clé du candidat qui identifie le mieux le sujet du tableau ou

qui est la plus significative pour tous les membres de l'organisation.

Vous commencez par travailler avec la table EMPLOYEES de la figure 8.12 . En

examinant les clés des candidats, vous décidez que le NUMÉRO D' EMPLOYÉ est un

bien meilleur choix pour une clé primaire que la combinaison du PRENOM

EMP et du NOM DE FAMILLE EMP , car les employés de Mike sont déjà habitués à

s'identifier par leurs numéros attribués. Utiliser EMPLOYEE N UMBER est

parfaitement logique, vous le sélectionnez donc comme clé primaire de la

table.
Figure 8.12 Structure de la table EMPLOYEES dans la base de données Mike's
Bikes.

Vous effectuez maintenant une dernière tâche avant de désigner le

NUMÉRO D' EMPLOYÉ comme clé primaire officielle de la table : vous vous assurez

absolument qu'il identifie exclusivement la valeur de chaque champ dans un

enregistrement donné. Ainsi, vous testez le NUMÉRO D' EMPLOYÉ en suivant ces

étapes.

1. Chargez la table EMPLOYEES avec des exemples de données.

2. Sélectionnez un enregistrement à des fins de test et notez la valeur actuelle

du NUMÉRO D' EMPLOYÉ .

3. Examinez la valeur du premier champ (celui immédiatement

après NUMÉRO D' EMPLOYÉ ) et posez-vous cette question :

Cette valeur de clé primaire identifie-t-elle exclusivement la valeur actuelle

de <fieldname> ?

1. Si la réponse est « oui », passez au champ suivant et répétez la question.

 2. Si la réponse est « non », supprimez le champ du tableau, passez au

champ suivant et répétez la question. (Assurez-vous de déterminer si

vous pouvez ajouter le champ que vous venez de supprimer à une autre

structure de table, le cas échéant, ou le supprimer complètement car il

est vraiment inutile.)

4. Continuez cette procédure jusqu'à ce que vous ayez examiné chaque valeur

de champ de l'enregistrement.

Vous savez que vous devrez supprimer tout champ contenant une valeur que

le NUMÉRO D' EMPLOYÉ n'identifie pas exclusivement. Cependant,

EMPLOYEE N UMBER identifie exclusivement la valeur de chaque champ dans

l'enregistrement de test, vous l'utilisez donc comme clé primaire officielle pour

la table EMPLOYEES et marquez son nom avec les lettres « PK » dans la

structure de la table . Vous répétez ensuite ce processus avec le reste des

tables de la nouvelle base de données de Mike jusqu'à ce que chaque table ait

une clé primaire.

N'oubliez pas de garder ces règles à l'esprit lorsque vous établissez les clés

primaires pour chaque table.

• Chaque table doit avoir une (et une seule) clé primaire.

• Chaque clé primaire de la base de données doit être unique ; deux tables ne

doivent pas avoir le même champ de clé primaire (sauf si elles

entretiennent une relation un-à-un ou si l'une d'entre elles est une table de

sous-ensemble).
Lorsque vous parcourez les tables de la base de données de Mike, vous vous

souvenez que la table SERVICES est une table de sous-ensemble. Vous l'avez

créé pendant leétape précédente du processus de conception (au chapitre 7 ),

et il représente une version plus spécifique du sujet représenté par la table

PRODUITS. Le champ P RODUCT N AME est ce qui relie actuellement la table

PRODUCTS à la table du sous-ensemble SERVICES. Cependant, vous savez

maintenant qu'une table de sous-ensemble doit avoir la même clé primaire que

la table à laquelle elle est liée, vous utiliserez donc P RODUCT N UMBER (la clé

primaire de la table PRODUCTS) comme clé primaire des SERVICES. tableau. La

figure 8.13 montre les tables PRODUITS et SERVICES avec leurs clés primaires.

Figure 8.13 Établissement de la clé primaire pour la table du sous-ensemble

SERVICES.
La dernière chose à faire est de mener des entretiens avec Mike et son équipe

et de passer en revue tout le travail que vous avez effectué sur les tables de la

base de données. Pendant que vous menez ces entretiens, assurez-vous de

vérifier les points suivants :

• Les sujets appropriés sont représentés dans la base de données.

• Les noms et descriptions des tables sont adaptés et significatifs pour tout le

monde.

• Les noms de champs conviennent et ont un sens pour tout le monde.

• Tous les champs appropriés sont affectés à chaque table.

A la fin de l'entretien, chacun s'accorde sur le fait que les tableaux sont en bon

état et que tous les sujets qui les concernent sont représentés dans la base de

données. Un seul point mineur est revenu au cours des discussions : Mike

souhaite ajouter un champ C ALL P RIORITY à la table VENDORS. Il existe des cas

dans lesquels plusieurs fournisseurs fournissent un produit particulier, et Mike

souhaite créer un moyen d'indiquer quel fournisseur il doit appeler en premier

si ce produit est inopinément en rupture de stock. Ainsi, vous ajoutez le

nouveau champ à la table VENDORS et mettez fin à l’entretien.

Résumé

Le chapitre s'ouvre sur une discussion sur l'importance des clés. Vous avez

appris qu’il existe différents types de clés et que chaque type joue un rôle

différent dans la base de données. Chaque clé remplit une fonction particulière,

telle que l'identification unique des enregistrements, l'établissement de

différents types d'intégrité et l'établissement de relations entre les tables. Vous

savez maintenant que vous pouvez garantir une structure de table solide en

vous assurant que les clés appropriées sont établies pour chaque table.
Nous avons ensuite discuté du processus d'établissement des clés pour chaque

table. Nous avons commencé par identifier les quatre principaux types de

clés : candidates, primaires, étrangères et non-clés. Tout d’abord, nous avons

examiné le processus d’établissement des clés candidates pour chaque

table. Vous avez découvert les éléments d'une clé candidate et comment vous

assurer qu'un champ (ou un ensemble de champs) est conforme à ces

éléments. Vous avez ensuite appris que vous pouvez créer et utiliser une clé

candidate artificielle lorsqu'aucun des champs d'une table ne peut servir de clé

candidate ou lorsqu'un nouveau champ constituerait une clé candidate plus

forte que n'importe lequel des champs de clé candidate existants.

Le chapitre s'est poursuivi avec une discussion sur les clés primaires. Vous

avez appris que vous sélectionnez une clé primaire dans le pool de clés

candidates d'une table et que la clé primaire est régie par un ensemble

d'éléments spécifiques. Nous avons ensuitea couvert un ensemble de

directives qui vous aident à déterminer quelle clé candidate utiliser comme clé

primaire. Ensuite, vous avez appris à vous assurer que la clé primaire choisie

identifie exclusivement un enregistrement donné et son ensemble de valeurs

de champ. Lorsque la clé primaire n'identifie pas exclusivement une valeur de

champ particulière, vous savez que vous devez supprimer le champ de la table

pour garantir l'intégrité structurelle de la table. Vous savez également que

chaque table doit avoir une clé primaire unique.

Vous avez ensuite appris à désigner toutes les clés candidates restantes

comme clés alternatives . Ces clés vous seront très utiles lorsque vous

implémenterez la base de données dans un programme SGBDR car elles

fournissent un moyen alternatif d'identifier un enregistrement donné. Nous

avons ensuite discuté du champ non-clé , qui est tout champ non désigné

comme clé candidate, primaire, alternative ou étrangère. Vous savez désormais

qu'un champ non clé représente une caractéristique du sujet de la table et que

la clé primaire identifie exclusivement sa valeur.

L'intégrité au niveau de la table a été le prochain sujet de discussion, et vous

avez appris qu'elle est établie grâce à l'utilisation de clés primaires et

appliquée par les éléments d'une clé primaire.

Le chapitre s'est terminé par quelques conseils sur la manière de mener

d'autres entretiens avec les utilisateurs et la direction. Vous savez maintenant

que ces entretiens vous permettent de revoir le travail que vous avez effectué

sur les tables et vous aident à vérifier et valider la structure actuelle de la base

de données.

Questions de révision

1. Énoncez les trois raisons pour lesquelles les clés sont importantes.

2. Quels sont les quatre principaux types de clés ?

3. A quoi sert une clé candidat ?

4. Énoncez quatre éléments des éléments d’une clé de candidat.

5. Vrai ou faux : une clé candidate peut être composée de plusieurs champs.

6. Une table peut-elle avoir plusieurs clés candidates ?

7. Qu'est-ce qu'une clé candidate artificielle ?

8. Quelle est la clé la plus importante que vous attribuez à une table ?

9. Pourquoi cette clé est-elle importante ?

10. Comment établir une clé primaire ?

11. Énoncez quatre éléments des éléments d'une clé primaire .

12. Que devez-vous faire avant de finaliser votre sélection de clé primaire ?

13. Qu'est-ce qu'une clé alternative ?

14. Que garantissez-vous en établissant l’intégrité au niveau de la table ?

15. Pourquoi devriez-vous revoir les structures initiales des tableaux ?

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
8. Clés
9. Spécifications du terrain
10. Relations entre les tables
7h 5min restantes

Spécifications du terrain

C’est depuis longtemps un axiome pour moi que les petites choses sont
infiniment les plus importantes.

—SHERLOCK H OLMES , LES AVENTURES DE S HERLOCK H OLMES _

Sujets abordés dans ce chapitre

Pourquoi les spécifications de terrain sont importantes

Intégrité au niveau du terrain

Anatomie d'une spécification de champ

Utilisation de spécifications de champ uniques, génériques et de réplication

Définition des spécifications de champ pour chaque champ de la base de

données

Exemple : Définition des spécifications de champ

Résumé

Questions de révision

Les champs constituent la base de la base de données. Ils représentent les

caractéristiques des sujets qui sont importants pour une organisation. Les

champs stockent les données que l'organisation utilise comme base

d'informations, informations essentielles à ses opérations quotidiennes, à son

succès et à sa croissance future. Malgré leur valeur inhérente, les domaines

restent les atouts les plus négligés, sous-utilisés et négligés de

l’organisation ! Souvent, peu ou pas de temps est consacré à garantir

l’intégrité structurelle et logique des champs de la base de données.

On dit et écrit beaucoup sur l’intégrité des données, mais peu est fait à ce

sujet. De nombreuses personnes pensent que garder un œil sur leur personnel

de saisie des données et disposer d’une interface utilisateur « infaillible » pour

la base de données minimisera considérablement les problèmes potentiels liés

aux données. Cette approche superficielle de l’intégrité des données découle

généralement d’une croyance erronée selon laquelle une bonne intégrité des

données prend trop de temps à établir. Il est important de noter, cependant,

que les personnes qui n'ont pas le temps d'établir l'intégrité des données

passent généralement beaucoup de temps à réparer leurs bases de données

mal conçues - généralement jusqu'à trois fois plus de temps qu'il leur en aurait

fallu pour concevoir la base de données. base de données correctement en

premier lieu !
Dans ce chapitre, vous apprendrez comment établir l'intégrité des données en

définissant les spécifications de champ pour chaque champ de la base de

données. Tout d’abord, vous découvrirez les trois ensembles d’éléments qui

composent une spécification de champ ; vous apprendrez ensuite à mener des

entretiens avec les utilisateurs et la direction pour solliciter leur aide dans la

définition des spécifications des champs.

Pourquoi les spécifications de terrain sont importantes

Malgré ce que vous avez peut-être entendu, le temps nécessaire pour établir

les spécifications de chaque champ de la base de données est

un investissement dans la création de données cohérentes et d'informations de

qualité : vous ne perdez pas de temps en effectuant ce processus. En fait, vous

perdrez plus de temps au final si vous n'effectuez que partiellement ce

processus ou si vous le négligez entièrement. Si vous ne respectez pas cette

obligation, vous serez forcément confronté (et souffrirez) de données

incohérentes et erronées et d'informations inexactes.

Les spécifications de terrain sont cruciales pour plusieurs raisons :

• Les spécifications de champ aident à établir et à appliquer l’intégrité au

niveau du champ. La mise en œuvre de ces spécifications vous permet de

garantir que les données de chaque champ sont cohérentes et valides.

• La définition des spécifications de champ pour chaque champ améliore

l’intégrité globale des données. N'oubliez pas que l'intégrité au niveau du

champ est l'une des quatre composantes de l'intégrité globale des

données. L'intégrité au niveau du champ améliore (dans une certaine

mesure) l'intégrité au niveau de la table que vous avez établie lors de

l'étape précédente du processus de conception. (Cela deviendra évident

lorsque vous travaillerez avec les éléments logiques de la spécification du

champ.)
• Définir les spécifications des champs vous oblige à acquérir une

compréhension complète de la nature et de la finalité des données

contenues dans la base de données. Comprendre les données signifie que
vous pouvez juger si les données sont vraiment nécessaires et importantes

pour l'organisation, et que vous pouvez apprendre à les utiliser à votre

meilleur avantage.

• Les spécifications des champs constituent le « dictionnaire de données » de

la base de données. Chaque spécification de champ stocke des données sur

les caractéristiques d'un champ particulier dans la base de

données. L'ensemble complet de spécifications que vous établissez pour

tous les champs de la base de données constitue un dictionnaire littéral de

la structure de la base de données. Ce dictionnaire de données est

particulièrement utile lorsque vous implémentez votre base de données

dans un SGBDR : vous pouvez l'utiliser comme guide pour créer les champs

et définir leurs propriétés fondamentales. Ces spécifications vous aideront

également à déterminer le type de procédures de saisie et de validation des

données que vous devez mettre en œuvre dans toute application d'interface

utilisateur que vous créez pour la base de données.

Gardez à l’esprit que les niveaux de cohérence, de qualité et d’exactitude des

données de la base de données (et des informations extraites de ces données)

sont directement proportionnels à la mesure dans laquelle vous remplissez ces

spécifications. L'établissement complet de chaque spécification de champ est

d'une importance primordiale si votre organisation dépend fortement des

informations que vous récupérez de la base de données.

Intégrité au niveau du terrain

Un champ atteint l'intégrité au niveau du champ une fois que vous avez défini

un ensemble complet de spécifications de champ pour le champ. L’intégrité au

niveau du terrain garantit ce qui suit.

• L'identité et la fonction d'un champ sont claires et tous les tableaux dans

lesquels il apparaît sont correctement identifiés.

• Les définitions de champs sont cohérentes dans toute la base de données.

• Les valeurs d'un champ sont cohérentes et valides.

• Les types de modifications pouvant être appliquées aux valeurs du champ

sont clairement identifiés.

Vous pouvez garantir qu’une structure de terrain est solide et conçue de

manière optimale lorsqu’elle dispose d’un ensemble complet de spécifications

de terrain et qu’elle est entièrement conforme aux éléments du champ

idéal. En fait, s’assurer que le champ est conforme aux éléments du champ

idéal rend la définition d’un ensemble de spécifications relativement facile.

Si vous avez des doutes persistants quant à la conformité d'un champ

particulier aux éléments du champ idéal, c'est le bon moment pour revoir ce

champ une fois de plus. Si vous déterminez qu'il n'est pas conforme, utilisez les

techniques appropriées pour résoudre le problème et apportez les ajustements

appropriés au tableau ; sinon, vous pouvez commencer le processus de

définition des spécifications de champ pour chaque champ de la base de

données. Voici à nouveau les éléments du champ idéal pour votre commodité.

• Il représente une caractéristique distincte du sujet du tableau.

• Il ne contient qu'une seule valeur.

• Il ne peut pas être déconstruit en composants plus petits.

• Il ne contient pas de valeur calculée ou concaténée.

• Il est unique dans toute la structure de la base de données.

• Elle conserve la majorité de ses caractéristiques lorsqu'elle apparaît dans

une ou plusieurs tables sous forme de clé étrangère.

Anatomie d'une spécification de champ

Une spécification de champ intègre divers éléments qui définissent chaque

attribut d'un champ. Tous les éléments de la spécification sont classés

en éléments généraux, éléments physiques ou éléments logiques. Ces

catégories d'éléments vous permettent de vous concentrer sur un aspect

distinct du domaine lorsque vous définissez la spécification et vous permettent

de trouver assez facilement un élément particulier.

Voici les éléments au sein de chaque catégorie.

• Éléments généraux : nom du champ, table parent, type de spécification,

spécification source, partagé par, alias, description.

• Éléments physiques : type de données, longueur, décimales, prise en

charge des caractères

• Éléments logiques : type de clé, structure de clé, unicité, prise en charge

nulle, valeurs saisies par, valeur requise, plage de valeurs, règle d'édition

La figure 9.1 montre un exemple de feuille de spécifications de terrain. Nous

utiliserons cette feuille (ou diverses parties de celle-ci) pour travailler sur des

exemples de spécifications de champ dans le reste du livre.

Figure 9.1 Feuille de spécifications sur le terrain.
Éléments généraux

Les éléments de la catégorie Éléments généraux représentent les attributs les

plus fondamentaux du domaine. Ils fournissent des informations sur l'objectif

du champ, le nom de la ou des tables dans lesquelles le champ apparaît et les

pseudonymes que le champ prend dans certaines circonstances.

Nom de domaine

Le nom du champ est l'ensemble de mots minimaux absolus qui identifient de

manière unique un champ particulier dans la base de données. Vous avez créé

et affiné les noms de champs plus tôt dans le processus de conception de la

base de données (voir Chapitre 7 , « Établir des structures de table »), vous

allez donc simplement prendre chaque nom et l'utiliser comme paramètre pour

cet élément.

Tableau parent

La table qui intègre un champ donné dans sa structure est appelée table

parent du champ . C'est le seul tableau dans lequel le champ apparaîtra sauf
si le champ participe à l'établissement d'une relation. (Vous en apprendrez
davantage sur cette exception au chapitre 10 , « Relations entre les tables ».)

Par exemple, STUDENTS est la table parent du champ STUDENT FIRST N AME .

Type de spécification

Les éléments que vous définissez pour un champ donné dépendent du type de

spécification que vous définissez pour le champ. Vous pouvez définir une

spécification de trois manières.

1. Unique : il s'agit de la spécification par défaut pour tous les champs, à

l'exception de ceux qui servent de modèle pour d'autres champs ou de ceux

qui participent à une relation de table en tant que clés étrangères. Vous

pouvez incorporer tous les éléments à l'exception de l'élément Spécification

source pour ce type de spécification, et les paramètres d'élément que vous

définissez s'appliqueront uniquement au champ indiqué dans l'élément Nom

du champ.

2. Générique : cette spécification sert de modèle pour d'autres spécifications

de champ et vous aide à garantir des définitions cohérentes pour les

champs ayant la même signification générale . Par exemple, vous pouvez

créer ce type de spécification pour un champ S TATE générique , puis l'utiliser

comme base pour tous les autres champs S TATE de la base de données. Les

champs tels que C UST S TATE ,E MP S TATE et V END S TATE ont tous la même

signification (ils représentent un État aux États-Unis), mais il existe une

distinction suffisamment évidente entre eux pour exiger qu'ils restent des

champs distincts. . (Si vous vous en souvenez, vous avez découvert les

champs génériques au chapitre 6 , « Analyse de la base de données

actuelle », lorsque vous développiez la liste préliminaire des champs et

au chapitre 7 lorsque vous travailliez avec les éléments du champ idéal.)

Une spécification générique nécessite que vous utilisiez un nom de champ

non spécifique et des paramètres d'élément aussi larges et généraux que

possible. Vous pouvez cependant incorporer n'importe quel élément à

l'exception de la table parent, partagé par, des alias et de la spécification

source.

3. Réplique : il s'agit de la spécification par défaut d'un champ basé sur un

champ générique ou d'un champ qui sert de clé étrangère dans une relation

de table, et elle tire la majorité de ses paramètres d'élément d'une

spécification existante. Vous pouvez incorporer des éléments qui n'étaient

pas déjà incorporés par la spécification source et vous pouvez modifier tous

les paramètres d'élément tirés de la spécification source.

Vous apprendrez comment définir chaque type de spécification dans la section

« Utilisation des spécifications de champ uniques, génériques et de réplication

» plus loin dans ce chapitre.

Spécification source

L'élément Source Spécification est défini uniquement sur une spécification de

réplication et indique le nom de la spécification de champ spécifique sur

laquelle la spécification actuelle est basée. (Vous verrez un bon exemple de cet

élément dans la section suivante.)

Partagé par

L'élément Shared By indique les noms des autres tables qui partagent ce

champ. Les seuls noms de table qui doivent apparaître ici sont ceux qui ont

une relation explicite avec la table parent du champ. Par exemple, supposons

que vous disposiez d'une table de données appelée EMPLOYEES qui est liée à

deux sous-ensembles de tables appelés PART-TIME EMPLOYEES et FULL-TIME

EMPLOYEES via un champ appelé E MPLOYEE ID N UMBER . Lorsque vous créez une

spécification de champ pour le NUMÉRO D'ID D' EMPLOYÉ , vous utiliserez «

EMPLOYÉS À TEMPS PARTIEL, EMPLOYÉS À TEMPS PLEIN » comme paramètre

pour cet élément.

Alias

L'alias est un nom (ou un ensemble de noms) que vous utilisez pour le champ

dans de très rares circonstances. Un cas dans lequel vous utiliseriez un alias

est celui où il doit y avoir deux occurrences du champ dans

la même table. Supposons qu'une organisation soit habituée à identifier ses

employés par des valeurs uniques dans un

champ EMPLOYEE ID NUMBER . Considérons maintenant la structure de la table

SUBSIDIAIRES dans la figure 9.2 (il s'agit d'une structure partielle uniquement).
Figure 9.2 Une table nécessitant deux occurrences du même champ.

Dans ce cas, chaque filiale a un président et un vice-président. Ces deux

personnes doivent être représentées dans le tableau en raison de leurs

positions au sein de la filiale. Il y a donc deux champs NUMÉRO D' ID

D' EMPLOYÉ dans la structure du tableau. Toutefois, une conception correcte de la

base de données impose qu'il ne puisse y avoir qu'une seule occurrence de ce

champ dans la table ; il y a un problème évident ici. La seule solution consiste à

utiliser un alias pour une ou les deux occurrences du champ E MPLOYEE ID

N UMBER . Par exemple, vous pouvez (par souci de clarté) utiliser P RESIDENT ID

comme alias pour la première occurrence de E MPLOYEE ID N UMBER et

V ICE P RESIDENT ID comme alias pour la deuxième occurrence de E MPLOYEE ID

N UMBER . Une fois les alias en place, les deux employés sont correctement

représentés dans le tableau. La figure 9.3 montre la structure révisée du

tableau.
Figure 9.3 Utilisation d'alias à la place des champs NUMÉRO D'ID D' EMPLOYÉ .

Bien que l’utilisation d’un alias soit acceptable dans ces circonstances, vous

devez l’utiliser de manière très judicieuse ; sinon, ils peuvent devenir difficiles

à gérer et à maintenir, éventuellement cacher ou déguiser la véritable

signification des champs d'origine et vous amener à mal comprendre ce que

représentent réellement les données. Ce problème deviendra encore plus clair

lorsque vous commencerez à établir des relations entre les tables.

Description

La description est une interprétation complète du domaine. Rédiger une

description de champ est extrêmement bénéfique car cela vous oblige (ainsi

que tous les membres de l'organisation) à réfléchir attentivement à la nature

des données qui seront stockées sur le terrain. Vous pouvez être relativement

sûr que le champ doit être affiné davantage si vous avez des difficultés à

rédiger une description appropriée.

Plus tôt dans le processus de conception de base de données, vous avez appris

un ensemble de directives pour rédiger une description de table. De même, il

existe un ensemble de directives qui régissent la manière dont vous rédigez

une description de champ appropriée :

Lignes directrices pour rédiger une description de champ

• Utilisez une déclaration qui identifie avec précision le champ et indique

clairement son objectif. La description doit compléter le nom du champ en

définissant ce que le champ représente. Il doit également indiquer le rôle du

champ dans la table ou sa relation avec le sujet de la table. Voici un

exemple d'une telle description :

CustCity : zone métropolitaine dans laquelle un client réside ou exerce ses

activités. Ceci fait partie intégrante de l’adresse complète d’un client.

• Rédigez une déclaration claire et succincte. La description doit être exempte

de phrases confuses ou ambiguës. Même si la description doit être aussi

complète que possible, utilisez le nombre minimum de mots nécessaire pour

transmettre les informations requises. Comme vous l'avez constaté avec les

descriptions de tableaux, les déclarations verbeuses sont difficiles à lire et à

comprendre.

• Évitez de reformuler ou de reformuler le nom du champ. Aucune de ces

pratiques ne fait quoi que ce soit pour éclairer l’identité ou le but du

domaine. N'oubliez pas que le but d'une description est de fournir une

interprétation complète du domaine. Voici un exemple de mauvaise

description :

CustLast Name : nom de famille d'un client.

Une description est bien plus utile lorsque vous l’écrivez de cette manière :

CustLast Name : le nom de famille d'un client, qu'il soit original ou par

mariage, que nous utilisons dans toutes les communications et

correspondances formelles avec ce client.

• Évitez d'utiliser du jargon technique, des acronymes ou des

abréviations. Même si certaines personnes au sein de l'organisation

comprennent ces types d'idiomes, il est préférable que vous utilisiez une

terminologie que tout le monde comprend. N'oubliez pas qu'une description

doit être aussi claire quepossible à quiconque le lit. Par exemple, vous

devriez éviter ce type de déclaration :

Numéro d'identification de l'employé : numéro unique utilisé pour identifier

un employé au sein de l'organisation. C'est une composante du SSP.

Le problème avec cette description est qu’il n’existe aucun moyen inhérent

de déterminer la signification de l’acronyme SSP. Vous pourriez résoudre ce

problème en épelant le terme complet, mais il serait préférable que vous

réaffirmiez l'objectif du champ.

• N’incluez pas d’informations spécifiques à la mise en œuvre. Il n'y a aucune

raison d'inclure le fait qu'un champ donné apparaît sur un écran de saisie de

données particulier ou est utilisé dans un morceau spécifique de code de

programmation. Ce type d'informations est plus approprié pour la phase de

mise en œuvre du processus global de développement de la base de

données.

• Ne faites pas dépendre cette description de la description d’un autre

champ. Chaque description doit être aussi complète que possible et

indépendante de toute autre description de la base de données. Les

descriptions interdépendantes introduisent une confusion inutile et peuvent

obscurcir par inadvertance la véritable identité et le véritable objectif du

domaine. Évitez d'utiliser une description telle que celle-ci :

Niveau de réapprovisionnement des articles : nombre minimum d'articles

qui doivent exister pour un produit particulier. (Voir la description pour la

quantité disponible.)
• N'utilisez pas d'exemples. Comme vous l'avez appris au chapitre 7 , utiliser

des exemples dans une description est une mauvaise idée car ils dépendent

d'informations supplémentaires pour transmettre leur pleine

signification. Vous pouvez garantir qu’une description est claire et succincte

en la gardant absolument exempte d’exemples.

La figure 9.4 montre la section Éléments généraux d'une feuille de

spécifications de champ pour un champ NUMÉRO D'ID D' EMPLOYÉ .

Figure 9.4 La catégorie Éléments généraux pour un champ NUMÉRO D'ID

D' EMPLOYÉ .

Éléments physiques

La catégorie Éléments physiques concerne la structure d'un champ. Ses

éléments sont exprimés en termes généraux car chaque programme SGBDR

les implémente de manière légèrement différente. L'établissement de ces

éléments au cours de cette phase du processus de conception vous aide à

garantir des définitions de champs cohérentes dans toute la base de données

et réduit le temps qu'il vous faudra pour implémenter les structures de champs

dans un programme SGBDR.

Type de données

L'élément Type de données indique la nature des données stockées par le

champ. Les trois types de données que nous utiliserons comme paramètre pour

cet élément sont :

1. Alphanumérique : ce type de données stocke toute combinaison de lettres,

de chiffres, de caractères du clavier ou de caractères spéciaux. Les

caractères du clavier incluent la virgule, le signe dollar, le point

d'exclamation, le signe de pourcentage et le point. Les caractères spéciaux

incluent le symbole du droit d'auteur, le symbole de la marque et le symbole

de pi.

2. Numérique : ce type de données stocke uniquement des nombres entiers et

des nombres réels. Il n'acceptera pas les nombres comportant des zéros non

significatifs (par exemple, 0000234) car ce ne sont pas de véritables

nombres.

3. DateTime : ce type de données stocke les dates, les heures ou une

combinaison des deux.

Gardez à l’esprit que le programme SGBDR que vous utilisez pour implémenter

la base de données disposera d’une plus grande variété de types de données à

votre disposition. J'utilise cependant ces types de données généraux pour

garder les choses aussi simples et claires que possible pendant le processus de

conception.
Longueur

L'élément Longueur spécifie le nombre total de caractères qu'un utilisateur

peut saisir pour une valeur de champ donnée. Le programme SGBDR que vous

utilisez pour implémenter la base de données déterminera le nombre

maximum de caractères que vous pouvez définir pour cet élément. Bien que

vous puissiez théoriquement définir l'élément de longueur pour n'importe quel

type de données, sachez que certains programmes SGBDR ne vous permettent

pas de spécifier une longueur pour un champ numérique. Au lieu de cela, le

programme SGBDR définit la longueur d'un champ numérique en fonction

du type de nombre stocké par le champ, tel qu'un entier, un entier long ou un

nombre réel.

Décimales

L'élément Decimal Places indique le nombre de chiffres à droite de la virgule

décimale dans un nombre réel. Le nombre de chiffres détermine la précision du

nombre réel. Par exemple, de nombreuses entreprises exigent que toutes les

valeurs monétaires comportent quatre chiffres de précision à droite de la

virgule décimale.

Prise en charge des personnages

L'élément Character Support indique le type de caractères qu'un utilisateur

peut saisir dans une valeur de champ donnée. La définition et l'application de

cet élément vous aident à garantir que l'utilisateur ne peut pas introduire de

données dénuées de sens dans le champ, améliorant ainsi l'intégrité au niveau

du champ.
Disons que vous travaillez avec un champ C UST S TATE et que son type de

données est alphanumérique. Ce type de données est approprié pour le champ

car il permet à un utilisateur d'incorporer des lettres dans le cadre d'une valeur

de champ donnée. Mais cela lui permet également d'utiliser des chiffres, des

caractères du clavier et des caractères étendus, ce qui signifie qu'il peut saisir

une valeur dénuée de sens dans le champ : il n'y a pas de noms d'état ni

d'abréviations d'état contenant des caractères autres que des lettres. Vous

résolvez ce problème en utilisant l'élément Character Support pour définir les

caractères que l'utilisateur peut incorporer dans une valeur de

champ. (J'aborde la question d'une combinaison valide de lettres plus loin dans

la section « Éléments logiques ».)

Vous pouvez choisir d'inclure ou d'exclure l'un des types de caractères

suivants.

• Lettres : toutes les lettres de l'alphabet , y compris les lettres de langues

étrangères telles que é et ñ.

• Nombres : de 0 à 9.

• Caractères du clavier : tout caractère standard autre que les lettres et les

chiffres, tel qu'un astérisque, une esperluette, un crochet, un signe

d'insertion, une virgule, un signe égal, un point d'exclamation, une

parenthèse, un signe de pourcentage, un point, un signe dièse, un point

d'interrogation, une citation, un point-virgule, une barre oblique ou barre

verticale. Notez que la feuille Spécifications des champs comprend des

exemples de caractères appartenant à cette catégorie.

• Caractères spéciaux : tout caractère que vous pouvez produire uniquement

via des combinaisons spécifiques de touches standard et des touches CTRL,

ALT et/ou SHIFT, ou à l'aide d'un logiciel spécial. Les caractères de cette

catégorie comprennent des symboles mathématiques complexes, le

symbole du droit d'auteur, les fractions, le symbole pi et le symbole de la

marque. La feuille Spécifications du champ comprend également des

exemples de ces caractères.

La figure 9.5 montre la section Éléments physiques d'une feuille de

spécifications de champ pour un champ NUMÉRO D'ID D' EMPLOYÉ .

Figure 9.5 La catégorie Éléments physiques pour un champ NUMÉRO D'ID

D' EMPLOYÉ .

Éléments logiques

La catégorie Éléments logiques concerne principalement les valeurs contenues

dans un champ. Ses éléments régissent des questions telles que son rôle dans

un tableau, si chaque valeur doit être unique, quand une valeur doit être saisie

et si une valeur peut être modifiée. La définition de ces éléments vous aide à

établir et à appliquer une grande partie de l’intégrité au niveau du champ.

Type de clé

L'élément Key Type désigne le rôle d'un champ dans une table, que vous avez

identifié lors de l'établissement d'une clé primaire pour la table. Comme vous

le savez déjà, un champ peut servir de clé non-clé, de clé primaire ou de clé

alternative. Au chapitre 10 , vous apprendrez tout sur les clés étrangères et

quand désigner un champ comme clé étrangère sur la feuille Spécifications du

champ.

Structure clé

L'élément Key Structure indique si un champ désigné comme clé primaire agit

comme une clé primaire simple (à champ unique) ou comme partie d'une clé

primaire composite (à champs multiples).

Unicité

Cet élément indique si les valeurs d'un champ sont uniques. Vous le définissez

sur « Unique » lorsque l' élément Key Type est défini sur « Primary » ; sinon,

vous définirez généralement cet élément comme « Non unique ».

Lorsque vous travaillez avec un champ non clé , réfléchissez à la manière dont

ses valeurs vont être utilisées afin de pouvoir déterminer si elles doivent être

uniques. Considérez la structure de la table DEPARTMENTS dans la figure 9.6 .

Figure 9.6 Les valeurs du NUMÉRO D'IDENTIFICATION DE L' EMPLOYÉ doivent -elles
être uniques ?.

Dans cet exemple, le champ EMPLOYEE ID N UMBER identifie la personne qui gère

un service particulier. En supposant qu'une personne ne soit autorisée à gérer

qu'un seul service à la fois, les valeurs de ce champ doivent être uniques ; par

conséquent, vous devez définir l'élément Unicité pour ce champ sur

« Unique ».

Prise en charge nulle

Null Support spécifie si un champ accepte Null. « Aucune valeur nulle » est le

paramètre que vous utiliserez couramment pour cet élément, en particulier

lorsqu'un champ sert de clé primaire ou de clé alternative, ou lorsque l'élément

Valeur requise du champ est défini sur « Oui ». Vous pouvez toutefois définir

cet élément sur « Nulls autorisés », lorsqu'il existe une raison valable pour

qu'un champ accepte les valeurs NULL. Le champ AC UST C OUNTY , par exemple,

doit accepter les valeurs nulles car un client peut ne pas connaître le nom du

comté dans lequel il vit. (Bien sûr, ce ne sera plus Null une fois qu'elle aura

fourni le nom du comté.)

N'oubliez pas que Null ne représente pas un espace : il représente une

valeur manquante ou inconnue . Les utilisateurs font souvent l'erreur d'utiliser

un espace pour représenter une valeur significative , telle que « Aucun », « Non

applicable », « Aucune réponse » et « Non recherché ». Si ces valeurs sont

valides pour un champ particulier, assurez-vous de les inclure dans l'élément

Plage de valeurs du champ. Surtout, utilisez les Nulls judicieusement

et n’utilisez pas de blancs !

Valeurs saisies par

L'élément Valeurs entrées par indique la source des valeurs d'un champ. Soit

un utilisateur entrera manuellement les valeurs dans le champ, soit un

programme d'application de base de données les saisira automatiquement ; le

programme d'application ne peut fournir des valeurs pour le champ que si la

personne qui a développé le programme lui a fourni un moyen de générer les

valeurs. Notez que le paramètre qui représente le programme d'application de

base de données est « Système ».

Valeur requise

L'élément Valeur requise indique si un utilisateur doit saisir une valeur pour un

champ. Bien que vous définissiez généralement cet élément sur « Non » pour

la plupart des champs d'une table, vous devez le définir sur « Oui » lorsque le

champ sert de clé primaire. Vous devrez peut-être également définir la valeur

requise sur « Oui » pour un champ tel que C UST Z IPCODE : une lettre ou un colis

que vous envoyez à un client donné doit inclure un code postal pour que le

service postal puisse le traiter correctement et avec précision.

Plage de valeurs

L'élément Range of Values spécifie toutes les valeurs valides possibles pour un

champ. Vous pouvez définir cet élément de différentes manières, par exemple

avec une limite inférieure et supérieure (1 000 à 9 999) ou avec une liste

spécifique de valeurs (« WA », « OR », « ID », « MT »). Vous pouvez établir une

plage de valeurs sous trois catégories :

1. Général : une collection complète de toutes les valeurs possibles pour ce

champ. Par exemple, la plage générale de valeurs d'un champ

C UST S TATE peut inclure toutes les abréviations valides pour chaque État des

États-Unis.
2. Spécifique à l'intégrité : une collection de valeurs basée sur le rôle du

champ dans une relation de table. (Vous apprendrez tout sur cette catégorie
au chapitre 10. )

3. Spécifique à l'entreprise : ensemble de valeurs générées par une exigence

commerciale particulière. Les organisations ont généralement diverses

exigences qui limitent la plage de valeurs d'un champ. Dans une

organisation qui exerce ses activités strictement dans le nord-ouest du

Pacifique, par exemple, la plage de valeurs valide pour un champ

C UST S TATE est « WA », « OR », « ID » et « MT ». (Vous en apprendrez

davantage sur cette catégorie au chapitre 11 , « Règles métier . »)

Vous vous préoccupez uniquement de la plage générale de valeurs au cours de

cette étape du processus de conception de base de données et vous reviendrez

sur l'élément Plage de valeurs ultérieurement lorsque vous établirez des

relations entre tables et des règles métier.

Il est important de noter que « Autre » et « Divers » sont deux valeurs que

vous ne souhaitez définir dans aucune catégorie de l'élément Plage de

valeurs. Les deux valeurs ne sont pas spécifiques et absolument dénuées de

sens dans ce contexte et sont un signe de paresse mentale dans la mesure où

leur simple présence indique la nécessité de revoir le domaine pour un

éventuel raffinement. Vous pouvez éviter toute confusion inutile et tout

problème potentiel en vous abstenant d'utiliser ces valeurs.

Modifier la règle

Cet élément désigne à quel moment un utilisateur peut saisir une valeur dans

un champ et s'il peut modifier cette valeur. Vous définissez cet élément sur

l'une de ces cinq options.

1. Entrez maintenant, modifications autorisées : un utilisateur doit saisir une

valeur pour ce champ lorsqu'il crée un nouvel enregistrement dans la table

parent du champ. Elle peut alors modifier la valeur à tout moment.

2. Entrer plus tard, modifications autorisées : un utilisateur a la possibilité de

saisir une valeur pour ce champ lors de la création d'un nouvel

enregistrement dans la table parent du champ. Cela n'implique en aucun

cas que la valeur du champ puisse être nulle à tout moment ; l'utilisateur

doit saisir une valeur pour ce champ à un moment donné dans un avenir

proche. Après avoir saisi la valeur, elle peut alors la modifier à tout moment.

3. Entrer maintenant, modifications non autorisées : un utilisateur doit saisir

une valeur pour ce champ lorsqu'il crée un nouvel enregistrement dans la

table parent du champ, mais il ne peut le modifier à aucun moment.

4. Saisir plus tard, modifications non autorisées : un utilisateur a la

possibilité de saisir une valeur pour ce champ lorsqu'il crée un nouvel

enregistrement dans la table parent du champ. Cela n'implique en aucun

cas que la valeur du champ puisse être nulle à tout moment ; l'utilisateur

doit saisir une valeur pour ce champ à un moment donné dans un avenir

proche. Après avoir saisi la valeur, elle ne peut à aucun moment la modifier.

5. Non déterminé à ce moment : la règle d'édition sera déterminée au moment

où la base de données est implémentée dans un programme SGBDR.

Note

Les options deux et quatre donnent à l'utilisateur le choix de saisir une valeur

dans le champ ultérieurement. Le temps dont dispose l'utilisateur pour saisir

une valeur sera déterminé et appliqué d'une manière ou d'une autre lorsque la

base de données sera implémentée dans un programme SGBDR.

La figure 9.7 montre la section Éléments logiques d'une feuille de spécifications

de champ pour un champ NUMÉRO D'ID D' EMPLOYÉ .

Figure 9.7 La catégorie Éléments logiques pour un champ NUMÉRO D'ID
D' EMPLOYÉ .

Utilisation de spécifications de champ uniques, génériques

et de réplication

Plus tôt dans ce chapitre, vous avez appris que vous pouviez définir une

spécification comme Unique, Générique ou Réplique. Vous pouvez vous assurer

que vous définissez le type de spécification approprié pour un champ donné en

suivant ces directives simples :

• Utilisez une spécification Unique pour tout champ qui n'apparaîtra qu'une

seule fois dans l'ensemble de la base de données ou pour un champ qui sert

de clé primaire.

• Utilisez une spécification générique pour un champ qui sert de modèle pour

d'autres champs de la base de données. N'oubliez pas d'utiliser un nom de

champ non spécifique et des paramètres d'élément aussi larges et généraux

que possible.
• Utilisez une spécification de réplication pour un champ que vous basez sur

un champ générique donné ou pour un champ qui sert de clé étrangère

dans une relation de table.

La figure 9.8 montre la spécification complète du champ Unique pour un champ

V ENDOR ID N UMBER .

Figure 9.8 Spécification de champ unique pour le champ V ENDOR ID N UMBER .

Voici quelques points à noter à propos de cette spécification.

1. Ce champ apparaît également dans la table PRODUITS, comme l'indique

l'élément général Partagé par. Ceci est à la fois raisonnable et nécessaire

car chaque produit doit être associé à un fournisseur spécifique. (Vous en

apprendrez davantage sur ce type de problème dans le chapitre suivant.)

2. Examinez les paramètres des éléments logiques Unicité, Prise en charge des

valeurs nulles, Valeur requise et Modifier la règle. Ils sont définis de cette

manière car l'élément Key Type est défini sur « Primary ». Vous devez en fait

utiliser ces paramètres d'élément pour tout champ servant de clé primaire.

La figure 9.9 montre la spécification complète du champ générique pour un

champ générique S TATE .

Figure 9.9 Spécification de champ générique pour un champ générique S TATE .

Prenez note de ces éléments :

1. La description est très générale, comme il se doit pour ce type de

spécification.

2. L’élément logique Étendue de valeurs est suffisamment large.

Ce champ (et sa spécification) sert désormais de modèle pour tous les autres

champs d'état que vous créez dans la base de données. Par exemple, vous

pouvez créer un champ V END S TATE basé sur le champ générique S TATE . Vous

allez définir une spécification de réplica pour le champ V END S TATE basée sur la

spécification générique du champ S TATE . Bien que la spécification de

réplication du champ V END S TATE tire ses paramètres d'élément initiaux de la spécification

générique du champ S TATE , vous pouvez modifier n'importe lequel des paramètres

d'élément de la spécification de réplication afin de pouvoir les personnaliser

complètement pour le V END S TATE . champ. La figure 9.10 montre les

spécifications personnalisées du champ Réplica pour le champ V END S TATE .

Figure 9.10 Spécifications du champ Réplique personnalisé pour le champ
V END S TATE .

Voici quelques points à noter concernant cette spécification.

1. Le nom du champ (V END S TATE ) indique avec précision ce que le champ

représente.
2. L’élément général Source Spécification fait correctement référence à la

spécification du champ générique S TATE .

3. L'élément Description est désormais spécifique à ce champ. Rappelons que

la description est plus générale dans la spécification source.

4. L'élément Plage de valeurs est désormais spécifique à ce champ ; c'était

beaucoup plus large dans la spécification de la source.

Dans le chapitre suivant, vous apprendrez comment définir une spécification de

champ de réplication pour un champ qui sert de clé étrangère.

Définition des spécifications de champ pour chaque champ

de la base de données

Maintenant que tous les champs nécessaires sont affectés à chaque table et

que vous comprenez les différents éléments d'une spécification de champ,

vous pouvez commencer le processus de définition d'une spécification de

champ pour chaque champ de la base de données. Ce processus vous prendra

beaucoup de temps, mais n'oubliez pas que vous travaillez avec diligence pour

établir l'intégrité au niveau du champ en vous assurant que les données sont

cohérentes, valides et aussi exemptes d'erreurs que possible. Tout votre travail

acharné portera ses fruits, car les informations que vous récupérez de la base

de données seront toujours actuelles et précises, et vous disposerez d'un

ensemble fiable de plans structurels que vous pourrez utiliser lorsque vous

implémenterez la base de données dans un programme SGBDR.

Vous pouvez garantir que les spécifications sont aussi complètes et précises

que possible en travaillant avec les utilisateurs et la direction pour les

définir. Ils peuvent fournir des informations sur les données et peuvent être

d'une aide particulière pour affiner les éléments logiques de la

spécification. Vous n'êtes pas obligé de parler à tout le monde dans

l'organisation, mais vous souhaitez essayer de rencontrer un nombre

représentatif de personnes qui connaissent très bien les données et la façon

dont elles sont utilisées. Planifiez autant de réunions que nécessaire (ou

possible) pour terminer le processus d’entretien et prenez le temps dont vous

avez besoin pour être aussi minutieux que possible. Surtout, ne vous précipitez

pas dans cette phase ! Cela ne fait que diminuer les avantages de votreefforts
globaux et augmente vos chances de commettre des erreurs inutiles.

La meilleure stratégie pour cette tâche est de définir autant de spécifications

que possible (aussi complètement que possible), puis de travailler avec les

participants pour compléter le reste. Lorsque vous travaillez avec les

spécifications d'un champ, faites preuve de discernement pour définir les

paramètres de chaque élément. Ne vous inquiétez pas si vos paramètres

semblent légèrement incorrects ou si vous avez des difficultés à définir les

paramètres de certains éléments : vous les examinerez de toute façon avec les

participants. Après avoir défini les spécifications pour tous les champs qui vous

sont familiers, commencez à rencontrer les participants pour travailler sur les

spécifications des champs restants.

Votre première tâche lors de la réunion initiale est d'expliquer les différents

éléments d'une spécification de domaine et de vous assurer que tout le monde

les comprend autant que possible. Fournir aux participants une formation brève

et succincte sur les éléments de la spécification leur donne les connaissances

dont ils ont besoin pour vous aider à définir correctement une

spécification. (Lors des réunions suivantes, examinez simplement les éléments

pour vous assurer que chacun se souvient de ce qu'ils représentent.)

Ensuite, passez en revue toutes les spécifications que vous avez définies et

demandez aux participants si les paramètres des éléments sont adaptés et

corrects. Dans certains cas, les participants révéleront de nouvelles

informations sur un champ qui affecteront la spécification de ce champ. Par

exemple, un participant peut se rappeler (incité par un sujet de discussion)

qu'un ensemble spécifique de valeurs a toujours été utilisé pour un domaine

particulier ; par conséquent, vous définissez l’élément Plage de valeurs du

champ pour refléter ces nouvelles informations. Assurez-vous d'examiner

chaque partie de la spécification, puis de passer à la spécification suivante

lorsque les participants n'ont plus de suggestions d'amélioration. Répétez ce

processus pour chaque spécification.

Travaillez désormais avec les participants sur les spécifications que vous n’avez

pas pu définir ou compléter. Essayez de travailler avec les personnes

les plus connaissent bien les champs en discussion, car ils savent

probablement quels paramètres doivent être utilisés pour la catégorie

Éléments logiques. Identifiez les paramètres d'élément appropriés pour chaque

champ et marquez-les sur la feuille Spécifications du champ. Une fois que vous

avez défini les spécifications pour chaque champ de la base de données,

l'ensemble du processus est terminé.

La conception de la nouvelle base de données est désormais presque

terminée. Dans le chapitre suivant, vous apprendrez comment établir des

relations entre les tables de la base de données. Les relations sont importantes
car elles permettent à une vue d'extraire simultanément des données de

plusieurs tables.

EXEMPLE : DÉFINITION DES SPÉCIFICATIONS DU TERRAIN

Maintenant que tous les champs appropriés sont attribués aux tables de la

base de données Mike's Bikes, il est temps de définir les spécifications de

champ pour chaque champ. Avant de rencontrer Mike et son équipe, vous

définissez autant de spécifications de terrain que possible. Aucun des tableaux

n'est inhabituel et les champs sont assez simples, vous n'aurez donc aucune

difficulté à définir les spécifications. La figure 9.11 montre les spécifications du

champ D ESCRIPTION DE PRODUIT dans la table PRODUITS.

Figure 9.11 Spécifications du champ D ESCRIPTION DU PRODUIT .
Vous rencontrez maintenant Mike et son équipe pour discuter des spécifications

de terrain que vous avez définies. Personne ne semble avoir de problèmes avec

aucune des spécifications ; tout le monde confirme que tous les réglages des

éléments semblent adaptés et corrects. Vous avez cependant une question

concernant le champ C ATEGORY de la table PRODUCTS : Vous souhaitez

connaître le paramètre approprié pour l'élément Range of Values. La réponse à

votre question est mitigée : personne ne semble connaître la liste complète des

catégories valides pour le champ, vous décidez donc de spécifier une plage

générale de valeurs pour l'instant. La figure 9.12 montre les éléments logiques

révisés pour le champ CATEGORIE .

Figure 9.12 Les éléments logiques du champ C ATEGORY dans la table PRODUITS.

Vous reviendrez sur ce champ (et ses éléments) lorsque vous établirez des

règles métier pour la base de données. Une fois ce problème résolu, votre

réunion, ainsi que le processus d'établissement des spécifications sur le terrain,

est terminé.
Résumé

Le chapitre s'ouvre sur une explication de l'importance des spécifications de

champ et des avantages que vous retirez de leur définition. Vous avez appris

que la définition de spécifications vous aide à établir et à appliquer l'intégrité

au niveau du champ, améliore l'intégrité globale des données et vous oblige à

acquérir une compréhension complète de la nature et de l'objectif des données

dans la base de données. Ce niveau de compréhension vous permet d’exploiter

les données à votre meilleur avantage.

Ensuite, nous avons discuté de l’anatomie d’une spécification de champ. Vous

connaissez désormais les trois catégories d'éléments du cahier des charges et

la feuille que vous utilisez pour les enregistrer. Nous avons ensuite discuté en

détail de chaque catégorie et de ses éléments. Comme vous le savez

désormais, la catégorie Éléments généraux représente les attributs les plus

élémentaires du domaine. Au cours de cette discussion, vous avez appris un

ensemble de lignes directrices qui vous aideront à rédiger une bonne

description de domaine. Vous avez également appris que vous pouviez définir

trois types de spécifications, vous permettant ainsi d'établir et de maintenir

des définitions de champs cohérentes. Nous avons ensuite examiné la

catégorie Éléments physiques et vous avez appris qu'elle se rapporte à la

structure du domaine. La catégorie Éléments logiques était le dernier sujet de

discussion dans cette section. Vous savez maintenant qu'il concerne

principalement les valeurs d'un champ et qu'il comprend des éléments tels que

le type de clé, la prise en charge des valeurs nulles, la plage de valeurs, la

règle d'édition.
Nous avons ensuite discuté de la manière d'utiliser chaque type de

spécification et vous avez appris un ensemble de lignes directrices qui vous

aideront à déterminer laquelle définir pour un domaine donné. Vous avez

également examiné des échantillons de spécifications et vous savez en quoi

elles diffèrent.

Le chapitre s'est terminé par une discussion sur la définition des spécifications

de champ pour chaque champ. Ici, vous avez appris que la meilleure façon de

garantir des spécifications complètes et précises est de travailler avec les

utilisateurs et la direction pour les définir. Vous devez d'abord définir autant de

spécifications que possible, puis travailler avec le personnel pour définir les

spécifications des champs restants. Vous avez également appris que vous

pouviez travailler avec le personnel pour affiner les spécifications que vous

aviez initialement définies.

Questions de révision

1. Énoncez deux raisons principales pour lesquelles les spécifications de terrain

sont importantes.

2. Que gagnez-vous à établir l’intégrité au niveau du terrain ?

3. Quelles sont les trois catégories d’éléments dans une spécification de champ

4. Nommez les trois types de spécifications.

5. Pourquoi est-il avantageux pour vous de rédiger une description de domaine

appropriée ?

6. Qu'indique l'élément Type de données ?

7. Qu'indique l'élément Support de personnage ?

8. Quels types de clés sont indiqués sur une spécification de champ ?

9. Vrai ou Faux : Null représente une valeur vide.

10. Quelle est la signification de l’élément Plage de valeurs ?

11. Quel est le but d'une règle de modification ?

12. Quand utilisez-vous une spécification générique ?

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
9. Spécifications du terrain
10. Relations entre les tables
11. Règles commerciales
4h 43min restantes

dix

Relations entre les tables

Rien ne remplace le confort procuré par une relation totalement considérée

comme allant de soi.

—IRIS MURDOCH __

Sujets abordés dans ce chapitre

Pourquoi les relations sont importantes

Types de relations

Identifier les relations existantes

Établir chaque relation

Affiner toutes les clés étrangères

Établir les caractéristiques de la relation

Intégrité au niveau des relations

Exemple : Identifier et établir des relations

Résumé

Questions de révision

Vous avez appris au chapitre 3 , « Terminologie », qu'une relation existe entre

deux tables lorsque l'on peut, d'une manière ou d'une autre, associer les

enregistrements de la première table à ceux de la seconde. Vous avez

également appris que chaque relation possède trois caractéristiques

distinctes : le type de relation qui existe entre les tables, la manière dont

chacune participe et le degré de participation de chaque table.

Dans ce chapitre, j'aborderai ces sujets plus en détail. Vous apprendrez d'abord

à identifier et à établir les relations entre les tables dans unbase de données,

puis comment définir les caractéristiques de chaque relation. Vous apprendrez

également à schématiser des tables et des relations, ce qui vous permettra de

créer une représentation graphique de l'ensemble de la structure de la base de

données.

Pourquoi les relations sont importantes

Une relation est un élément important d'une base de données relationnelle.

• Il établit une connexion entre une paire de tables logiquement liées les unes

aux autres. Une paire de tables est logiquement liée via les données que
chacune contient. Par exemple, considérons les tableaux de la figure 10.1 .

Figure 10.1 Une paire de tables logiquement liées.

Il existe une relation logique entre les données de la table STUDENTS et les

données de la table STUDENT INSTRUMENTS. Un élève peut consulter un ou

plusieurs instruments au cours d'une année scolaire. Ainsi, un

enregistrement de la table ÉTUDIANTS (représentant l'élève) peut être lié à

un ou plusieurs enregistrements de la table INSTRUMENTS ÉTUDIANTS

(représentant les instruments particuliers que l'élève vérifie). dehors).

• Cela permet d'affiner davantage les structures des tables et de minimiser

les données redondantes. Au fur et à mesure que vous établissez une

relation entre une paire de tables, vous apporterez inévitablement des

modifications mineures à la table.structures. Ces améliorations rendront les

structures plus efficaces et minimiseront les données redondantes que les

tables peuvent contenir.

• C'est le mécanisme qui vous permet d'extraire des données de plusieurs

tables simultanément. Dans le chapitre 12 , « Vues », vous découvrirez

comment une relation vous permet de construire une vue à l'aide des

champs de deux ou plusieurs tables liées.

Une relation correctement définie garantit l’intégrité de la relation, ce qui

garantit que la relation elle-même est fiable et solide. (Rappelez-vous que

l'intégrité au niveau des relations est une composante de l'intégrité globale des

données.) Vous ne pouvez profiter des nombreux avantages qu'offre une base

de données relationnelle que lorsque vous établissez chaque relation avec soin

et correctement. Si vous ne le faites pas, vous aurez du mal à travailler avec

les données de plusieurs tables et vous rencontrerez certainement des

problèmes lorsque vous tenterez d'insérer, de mettre à jour ou de supprimer

des enregistrements dans des tables associées. Vous en apprendrez davantage

sur ces types de problèmes plus tard, au fur et à mesure du déroulement du

processus de conception.

Types de relations

Avant de commencer à établir des relations entre les tables de la base de

données, vous devez savoir quels types de relations peuvent exister entre une

paire de tables donnée. Savoir les identifier correctement est une compétence

inestimable pour réussir la conception d’une base de données.

Trois types spécifiques de relations peuvent exister entre une paire de

tables : un-à-un, un-à-plusieurs et plusieurs-à-plusieurs. Les tables ne

participent qu'à un seul type de relation à un moment donné. (Si vous avez

défini votre énoncé de mission et vos objectifs de mission aussi précisément

que possible, vous aurez rarement besoin de modifier le type de relation entre

une paire de tables. Seuls des changements majeurs dans l'une ou l'autre des

structures de la table pourraient vous amener à modifier la relation. .)

Note
La discussion sur chaque type de relation commence par un exemple

générique de relation. Apprendre à visualiser une relation de manière

générique vous permet de comprendre le principe qui se cache derrière la

relation elle-même. Après avoir compris comment et pourquoi la relation

fonctionne, vous serez en mesure de déterminer assez facilement si elle existe

entre une paire de tables donnée.

Chaque discussion comprend également un exemple de la façon de

schématiser la relation. Je fournis des instructions spéciales concernant le

processus de création de diagrammes, le cas échéant, et j'explique les

symboles incorporés dans le diagramme si nécessaire. Cela vous permet

d'apprendre la méthode de création de diagrammes à un rythme raisonnable et

vous évite d'avoir à mémoriser l'ensemble des symboles du diagramme en

même temps.

La figure 10.2 montre les premiers symboles que vous utiliserez pour

schématiser une relation entre tables.

Figure 10.2 Symboles de diagramme pour une table de données et une table
de sous-ensembles.
Relations individuelles

Une paire de tables entretient une relation un-à-un lorsqu'un seul

enregistrement de la première table est lié à un seul enregistrement de la

deuxième table et qu'un seul enregistrement de la deuxième table est lié à un

seul enregistrement de la première table. La figure 10.3 montre un exemple

générique de relation un-à-un.

Figure 10.3 Un exemple générique de relation un-à-un.

Comme vous pouvez le constater, un seul enregistrement de la TABLE A est lié

à un seul enregistrement de la TABLE B, et un seul enregistrement de la TABLE

B est lié à un seul enregistrement de la TABLE A. Une relation un-à-un est

généralement (mais pas toujours) ) implique une table de sous-ensembles . La

figure 10.4 montre un exemple de relation individuelle typique que vous

pourriez trouver dans une base de données du service des ressources

humaines d'une organisation. Cet exemple illustre également une situation

dans laquelle aucune des tables n'est une table de sous-ensemble.

Figure 10.4 Un exemple typique de relation un-à-un.

Bien que les champs de ces tables puissent être combinés en une seule table,

le concepteur de la base de données a choisi de placer les champs visibles par

toute personne dans l'organisation dans la table EMPLOYÉS et les champs

visibles uniquement par le personnel autorisé dans la table

RÉMUNÉRATION. . Un seul enregistrement est requis pour stocker les données

de rémunération d'un employé donné. Il existe donc une relation univoque

distincte entre un enregistrement de la table EMPLOYEES et un enregistrement

de la table COMPENSATION.

La figure 10.5 montre un exemple générique de la façon dont vous créez un

diagramme de relation pour une relation un-à-un.

Figure 10.5 Schéma d'une relation un-à-un.

La ligne qui apparaît entre les tableaux du diagramme indique le type de

relation et vous utilisez une ligne particulière pour chaque type. Plus loin dans

ce chapitre, vous apprendrez comment modifier la ligne afin qu'elle affiche

également les caractéristiques de la relation. La figure 10.6 montre le

diagramme de relation pour les tables EMPLOYÉS et RÉMUNÉRATION de

la figure 10.4 . (Notez qu'un symbole de table de données représente chaque

table.)

Figure 10.6 Le diagramme de relation pour les tables EMPLOYÉS et

RÉMUNÉRATION.
Relations un-à-plusieurs

Une relation un-à-plusieurs existe entre une paire de tables lorsqu'un seul

enregistrement de la première table peut être lié à un ou plusieurs

enregistrements de ladeuxième table, mais un seul enregistrement de la

deuxième table ne peut être lié qu'à un seul enregistrement de la première

table. Regardons un exemple générique de ce type de relation.

Supposons que vous travaillez avec deux tables, TABLE A et TABLE B, qui ont

une relation un-à-plusieurs entre elles. En raison de la relation, un seul

enregistrement de la TABLE A peut être lié à un ou plusieurs enregistrements

de la TABLE B. La figure 10.7 montre la relation du point de vue de la TABLE A.

Figure 10.7 Une relation un-à-plusieurs du point de vue du TABLEAU A.

À l'inverse, un seul enregistrement du TABLEAU B peut être lié à un seul

enregistrement du TABLEAU A. La figure 10.8 montre la relation du point de vue

du TABLEAU B.
Figure 10.8 Une relation un-à-plusieurs du point de vue du TABLEAU B.

Il s’agit de loin de la relation la plus courante qui existe entre une paire de

tables dans une base de données, et la plus facile à identifier. C’est crucial du

point de vue de l’intégrité des données, car cela permet d’éliminer les données

en double et de maintenir les données redondantes au minimum absolu. La

figure 10.9 montre un exemple courant de relation un-à-plusieurs que vous

pourriez trouver dans une base de données pour un magasin de location

d'équipement.

Figure 10.9 Un exemple typique de relation un-à-plusieurs.

Un client peut extraire n'importe quel nombre d'articles, de sorte qu'un seul

enregistrement de la table CLIENTS peut être associé à un ou plusieurs

enregistrements de la table LOCATIONS CLIENTS. Toutefois, un seul article est

associé à un seul client à un moment donné, de sorte qu'un seul

enregistrement de la table CUSTOMER RENTALS est lié à un seul

enregistrement de la table CUSTOMERS.

La figure 10.10 montre un exemple générique de la façon dont vous créez un

diagramme de relation pour une relation un-à-plusieurs.

Figure 10.10 Représentation schématique d'une relation un-à-plusieurs.

Notez que le symbole de la patte d'oie est toujours situé à côté du tableau du

côté « plusieurs » de la relation. La figure 10.11 montre le diagramme de

relations pour les tables CLIENTS et LOCATIONS CLIENTS de la figure 10.9 .

Figure 10.11 Le diagramme de relation pour les tables CLIENTS et LOCATIONS
CLIENTS.

Relations plusieurs-à-plusieurs

Une paire de tables entretient une relation plusieurs-à-plusieurs lorsqu'un seul

enregistrement de la première table peut être lié à un ou plusieurs

enregistrements de la deuxième table et qu'un seul enregistrement de la

deuxième table peut être lié à un ou plusieurs enregistrements de la premier

tableau.

Supposons encore une fois que vous travaillez avec TABLE A et TABLE B et qu'il

existe une relation plusieurs-à-plusieurs entre elles. En raison de la relation, un

seul enregistrement de la TABLE A peut être lié à un ou plusieurs

enregistrements (mais pas nécessairement tous) de la TABLE B. Inversement,

un seul enregistrement de la TABLE B peut être lié à un ou plusieurs

enregistrements (mais pas nécessairement tous) ) dans le TABLEAU A. La figure

10.12 montre la relation du point de vue de chaque tableau.

Il s'agit de la deuxième relation la plus courante qui existe entre une paire de

tables dans une base de données. Cela peut être un peu plus difficile à

identifier qu’une relation un-à-plusieurs, vous devez donc vous assurer

d’examiner attentivement les tableaux. La figure 10.13 montre un exemple

typique de relation plusieurs-à-plusieurs que vous pourriez trouver dans une

base de données scolaire, ce qui s'avère être un exemple classique de ce type

de relation.

Figure 10.12 Une relation plusieurs-à-plusieurs du point de vue du TABLEAU A

et du TABLEAU B.
Figure 10.13 Un exemple typique de relation plusieurs-à-plusieurs.

Un élève peut fréquenter un ou plusieurs cours au cours d'une année scolaire,

donc un seul enregistrement de la table ÉTUDIANTS peut être lié à un ou

plusieurs enregistrements de la table CLASSES. A l’inverse, un ou plusieurs

étudiants fréquenteront un cours donné, donc un seul enregistrement de la

table CLASSES peut être lié à un ou plusieurs enregistrements de la table

ÉTUDIANTS.

La figure 10.14 montre un exemple générique de la façon dont vous créez un

diagramme de relation pour une relation plusieurs-à-plusieurs.

Figure 10.14 Représentation schématique d'une relation plusieurs-à-
plusieurs.

Dans ce cas, un symbole de patte d'oie est situé à côté de chaque table. La

figure 10.15 montre le diagramme de relation pour les tables ÉTUDIANTS et

CLASSES de la figure 10.13 .

Figure 10.15 Le diagramme de relation pour les tables ÉTUDIANTS et

CLASSES.
Problèmes avec les relations plusieurs-à-plusieurs

Une relation plusieurs-à-plusieurs présente une particularité inhérente que

vous devez traiter avant de pouvoir utiliser efficacement les données des

tables impliquées dans la relation. Le problème est le suivant : comment

associer facilement les enregistrements de la première table aux

enregistrements de la deuxième table pour établir la relation ? Cette question

est importante car vous rencontrerez des problèmes tels que ceux-ci si vous

n'établissez pas correctement la relation :

• Récupérer des informations de l'une des tables sera fastidieux et quelque

peu difficile.

• L'une des tables contiendra une grande quantité de données redondantes.

• Des données en double existeront dans les deux tables.

• L'insertion, la mise à jour et la suppression de données seront difficiles.

Les développeurs novices et inexpérimentés utilisent deux méthodes courantes

dans une tentative futile de résoudre cette situation. Je vais vous montrer

comment appliquer ces méthodes en utilisant les tableaux ÉTUDIANTS et

CLASSES de la figure 10.16 comme exemples.

Figure 10.16 Structures des tables ÉTUDIANTS et CLASSES.

Note

À mesure que cet exemple se déroule, gardez à l’esprit que chaque relation

plusieurs-à-plusieurs que vous rencontrerez présentera les mêmes problèmes.

Comme vous pouvez le constater, aucune connexion réelle n'existe entre les

deux tables. Vous n'avez donc aucun moyen d'associer les enregistrements

d'une table aux enregistrements de l'autre table. La première méthode que

vous pouvez utiliser pour tenter d'établir une connexion consiste à prendre un

champ d'une table et à l'incorporer un nombre donné de fois dans l'autre

table. (Cette approche plaît généralement aux personnes habituées à travailler

avec des feuilles de calcul.) Par exemple, vous pouvez prendre le champ

ID ÉTUDIANT de la table ÉTUDIANTS et l'incorporer dans la structure de la table

CLASSES, créant ainsi autant de copies du champ que nécessaire. pour

représenter le nombre maximum d’élèves pouvant assister à n’importe quel

cours. La figure 10.17 montre la version révisée de la structure du tableau

CLASSES.
Figure 10.17 Incorporation des champs STUDENT ID dans la structure de la table
CLASSES.

Cette structure est probablement problématique, vous pouvez donc essayer de

prendre le champ C LASS ID de la table CLASSES et de l'incorporer à la place

dans la structure de la table STUDENTS. La figure 10.18 montre la version

révisée de la structure du tableau STUDENTS.

Figure 10.18 Incorporation des champs C LASS ID dans la structure de la table

STUDENTS.
Ces structures vous semblent-elles (vaguement) familières ? Ils devraient. En

utilisant cette méthode, tout ce que vous avez fait est d'introduire un champ à

plusieurs valeurs « aplati » dans la structure de la table. Ce faisant, vous avez

également présenté les problèmes associés à un champ à valeurs multiples. (Si

nécessaire, consultez le chapitre 7 , « Établir des structures de table ».) Bien

que vous sachiez comment résoudre un champ à plusieurs valeurs, ce n'est pas

une bonne manière d'établir la relation.

La deuxième méthode que vous pourriez essayer d’utiliser est simplement une

variante de la première méthode. Dans ce cas, vous prenez un ou plusieurs

champs d'une table et incorporez une seule instance de chaque champ dans

l'autre.tableau. Par exemple, vous pouvez prendre les champs C LASS ID,

C LASS N AME et I NSTRUCTOR ID de la table CLASSES et les incorporer dans la table

STUDENTS pour identifier les classes dans lesquelles un étudiant est

actuellement inscrit. Cela peut sembler être une nette amélioration par rapport

à la première méthode, mais vous verrez que des problèmes découlent de

telles modifications lorsque vous chargez la table ÉTUDIANTS révisée avec des

exemples de données.

La figure 10.19 illustre clairement les problèmes que vous rencontrerez en

utilisant cette méthode.

Figure 10.19 Tableau ÉTUDIANTS révisé avec des exemples de données.

• Le tableau contient des champs en double inutiles. Vous avez tout appris

sur les champs en double inutiles et les problèmes qu'ils posent au chapitre

7 , vous savez donc que les utiliser ici n'est pas une bonne idée. En outre, il

est très probable que les champs NOM DE LA COURSE et ID DE L' INSTRUCTEUR ne

soient pas appropriés dans la table ÉTUDIANTS : le champ ID DE

LA COURSE identifie suffisamment la classe, et c'est en réalité tout ce dont

vous avez besoin pour identifier les cours qu'un élève suit. .

• Il existe une grande quantité de données redondantes. Même si vous

supprimez les champs C LASS N AME et I NSTRUCTOR ID de la table STUDENTS, le

champ C LASS ID produira toujours beaucoup de données redondantes.

• L'insertion d'un nouvel enregistrement est difficile. Si vous saisissez un

enregistrement dans la table ÉTUDIANTS pour une nouvelle classe (au lieu

de le saisir dans la table CLASSES) sans saisir également les données de

l'étudiant, les champs relatifs à l'étudiant seront nuls, y compris la clé

primaire de la table ÉTUDIANTS ( Étudiant IDENTIFIANT). Cela déclenchera

automatiquement une violation des éléments d'une clé primaire car la clé

primaire ne peut pas être nulle ; par conséquent, vous ne pouvez pas

insérer l'enregistrement dans la table tant que vous n'êtes pas en mesure

de fournir une valeur de clé primaire appropriée.

• Supprimer un enregistrement est difficile. Cela est particulièrement vrai si

les seules données concernant une nouvelle classe ont été enregistrées

dans le dossier de l'élève que vous souhaitez supprimer. Notez par exemple

le record de Diana Price. Si Diana décide de ne suivre aucun cours cette

année et que vous supprimez son dossier, vous perdrez les données du

cours « Introduction à la conception de bases de données ». Cela pourrait ne

pas créer de problème sérieux, à moins que quelqu'un ait négligé de saisir

également les données sur cette classe dans la table CLASSES. Après avoir

supprimé l'enregistrement de Diana, vous devrez ressaisir toutes les

données de la classe dans la table CLASSES.

Heureusement, vous n'aurez à vous soucier d'aucun de ces problèmes car vous

allez apprendre la bonne façon d'établir une relation plusieurs-à-plusieurs.

Relations d'auto-référencement

Une relation d'auto-référencement n'existe pas entre une paire de tables, c'est

pourquoi elle n'est pas mentionnée au début de cette section. Il s'agit plutôt

d'une relation qui existe entre les enregistrements d'une table. Ironiquement,

vous considérerez toujours cela tout au long du processus de conception

comme une relation de table.

Une table entretient une relation d'auto-référencement (également appelée

relation récursive ) avec elle-même lorsqu'un enregistrement donné de la table

est lié à d'autres enregistrements de la table. Semblable à son homologue à

double table,une relation d'auto-référencement peut être un-à-un, un-à-

plusieurs ou plusieurs-à-plusieurs.

Un par un

Une relation un-à-un d'auto-référencement existe lorsqu'un enregistrement

donné de la table ne peut être lié qu'à un seul autre enregistrement de la

table. La table MEMBERS de la figure 10.20 est un exemple de table avec ce

type de relation. Dans ce cas, un membre donné ne peut parrainer qu'un seul

autre membre au sein de l'organisation ; le champ ID S PONSOR stocke le numéro

d'identification du membre agissant en tant que sponsor. A noter que Susan

Black est la marraine de Tom Wickerath.

Figure 10.20 Exemple de relation un-à-un auto-référencée.

La figure 10.21 montre comment schématiser ce type de relation.

Figure 10.21 Représentation schématique d'une relation un-à-un auto-
référencée.

Un à plusieurs

Une table entretient une relation un-à-plusieurs auto-référencée avec elle-

même lorsqu'un enregistrement donné dans la table peut être lié à un ou

plusieurs autres enregistrements.dans le tableau. La figure 10.22 montre un

exemple dans lequel un client donné peut référer d'autres clients à

l'organisation. Le champ RÉFÉRÉ PAR stocke le numéro d’identification du client

effectuant la référence. Notez que Paul Litwin a fait référence à la fois à Andy

Baron et à Mary Chipman.

Figure 10.22 Exemple de relation un-à-plusieurs auto-référencée.

La figure 10.23 montre comment schématiser une relation un-à-plusieurs auto-

référencée.

Figure 10.23 Représentation schématique d'une relation un-à-plusieurs auto-

référencée.

Plusieurs à plusieurs

Une relation plusieurs-à-plusieurs auto-référencée existe lorsqu'un

enregistrement donné dans la table peut être lié à un ou plusieurs autres

enregistrements dans la table et qu'un ou plusieurs enregistrements peuvent

eux-mêmes être liés à l'enregistrement donné. Cela peut paraître quelque peu

déroutant au premier abord, mais l'exemple de la figure 10.24 devrait aider à

clarifier la question.
Figure 10.24 Exemple de relation plusieurs-à-plusieurs auto-référencée.

Dans ce cas, une pièce particulière peut comprendre plusieurs pièces

constitutives différentes, et elle peut elle-même être un composant d'autres

pièces. Par exemple, un ensemble de serrage (ID de pièce 704) est composé

d'un boulon de fixation (ID de pièce 703), d'une pince inférieure (ID de pièce

702) et d'une pince supérieure (ID de pièce 701). De plus, l'ensemble de

serrage est lui-même un composant d'un ensemble siège (ID de pièce 707) et

d'un ensemble cadre (ID de pièce 711). La figure 10.25 montre comment

schématiser ce type de relation.

Figure 10.25 Représentation schématique d'une relation plusieurs-à-plusieurs

auto-référencée.
 Note

Avant de commencer à travailler sur les exemples du reste du chapitre, c'est le

bon moment pour vous rappeler un principe que j'ai présenté dans

l'introduction :

Concentrez-vous sur le concept ou la technique et les résultats escomptés, et

non sur l'exemple utilisé pour l'illustrer .

Il existe sans aucun doute de nombreuses façons de relier les tables dans ces

exemples (et également dans les études de cas), en fonction du rôle de chaque

table dans une base de données donnée. La manière dont j’utilise les exemples

ici n’est pas importante ; ce qui est important, ce sont les techniques que

j'utilise pour identifier et établir des relations entre les tables. Après avoir

appris ces techniques, vous pouvez identifier et établir des relations pour

n'importe quelle paire de tables dans n'importe quel contexte que vous

pourriez rencontrer.

Maintenant que vous connaissez les différents types de relations entre tables,

votre tâche suivante consiste à identifier les relations qui existent actuellement

entre les tables de la base de données.

Identifier les relations existantes

Lorsque vous rédigiez les descriptions des tables plus tôt dans le processus de

conception de la base de données (au chapitre 7 , pour être exact), vous avez

réuni un groupe représentatif d'utilisateurs et de direction pour vous aider dans

cette tâche. Ces personnes ont également été désignées comme représentants

de l'organisation et ont reçu le pouvoir d'aider au processus de prise de

décision tout au long du processus de conception de la base de données. (Au

moins, c'est l'hypothèse actuelle à des fins de discussion et d'exemple.) Vous

allez maintenant organiser à nouveau des réunions avec ce groupe afin qu'il

puisse vous aider à identifier les relations de table existantes. Ces personnes

peuvent apporter une contribution précieuse car elles ont probablement une

bonne perspective sur la manière dont les différents sujets (ou tableaux) sont

liés. Même si leurs perceptions de la manière dont ces sujets sont liés ne sont

pas toujours complètes ou exactes, leurs contributions seront néanmoins utiles

pour identifier la plupart des relations.

Commencez le processus d'identification des relations en créant une matrice

de toutes les tables de votre base de données. (Vous pouvez le faire sur une

feuille de papier, untableau blanc ou un tableur.) Par exemple, supposons que

vous travaillez avec ces tableaux :

BÂTIMENTSLA FACULTÉÉTUDIANTS

DES CLASSESPIÈCES

COMPENSATIONPERSONNEL

Répertoriez chacun des tableaux en haut de la matrice, puis à nouveau en bas

à gauche de la matrice ; assurez-vous que les noms des tables sont dans le

même ordre. La figure 10.26 illustre à quoi devrait ressembler la matrice.

Figure 10.26 Mise en place d'une matrice de tableau pour aider à identifier
les relations existantes.

Sélectionnez un tableau sur la gauche comme point de départ et déterminez

s'il a une relation avec l'un des tableaux répertoriés en haut, tout en

parcourant la matrice. (Peu importe que vous travailliez par le haut ou par le

côté. Assurez-vous simplement de travailler de manière cohérente, car cela

rendra la tâche beaucoup plus facile.)

Gardez à l'esprit que vous recherchez uniquement des relations directes : il doit

exister une connexion spécifique entre les tables participant à la relation. Par

exemple, la table CLASSES a une relation directe avec la table STUDENTS car

un ou plusieurs étudiants peuvent assister à un cours donné. A l'inverse, la

table CLASSES a une relation indirecte avec la table STAFF via la table

FACULTY ; c'est un membre du corps professoral quienseigne une classe, pas

un membre du personnel. (Vous n'avez pas encore à vous soucier des relations

indirectes.)
Pendant que vous travaillez avec deux tableaux, posez des questions aux

participants sur les enregistrements de chaque tableau. Votre objectif est de

déterminer la relation entre un seul enregistrement d'une table et un ou

plusieurs enregistrements de l'autre table, et vice versa. (N'oubliez pas que

chaque enregistrement représente une instance unique du sujet représenté par

le tableau.) Lorsque vous arrivez à un point où vous examinez le même tableau

des deux côtés de la matrice, essayez de déterminer la relation entre un

enregistrement donné dans le table vers un ou plusieurs autres

enregistrements dans la table elle-même.

Les deux types de questions que vous pouvez poser sont :

1. Associative : Il s'agit d'un type de question simple et directe que vous

pouvez formuler de manière générique comme suit : Un seul enregistrement

dans (nom de la première table) peut-il être associé à un ou plusieurs

enregistrements dans (nom de la deuxième table) ? En considérant la

matrice de la figure 10.26 , vous pourriez poser une question associative

telle que celle-ci :

Un seul enregistrement dans CLASSES peut-il être associé à un ou plusieurs

enregistrements dans BUILDINGS ?

Vous pouvez utiliser ce type de question pour déterminer si une table a une

relation d'auto-référencement en apportant deux modifications mineures à

la question elle-même : Une seule ( forme singulière du nom de la table )

peut-elle être associée à une ou plusieurs ( forme plurielle du nom de la

table). nom de la table )? Par exemple, voici une question que vous pourriez
poser pour la table STAFF :

Un même membre du personnel peut-il être associé à un ou plusieurs autres

membres du personnel ?
2. Contextuel : ce type de question oppose une seule instance du sujet

représenté par le premier tableau à plusieurs instances du sujet représenté

par le deuxième tableau. LàIl existe deux catégories dans ce type de

questions : orientées vers la propriété et orientées vers l'action.

1. Les questions axées sur la propriété incluent des mots ou des

expressions tels que posséder, posséder, faire partie de et contenir. Voici

un exemple de ce type de question :

Une seule commande peut-elle contenir un ou plusieurs produits ?

Vous pouvez utiliser cette question pour tester une relation d'auto-

référence en apportant les mêmes modifications que vous avez

apportées à la question associative. Voici un exemple de question que

vous pourriez poser pour une table PARTS :

Une seule pièce peut-elle contenir une ou plusieurs autres pièces ?

2. Les questions orientées vers l'action intègrent des verbes d'action tels

que fabriquer, visiter, placer, enseigner et assister. Voici un exemple de

ce type de question :

Un seul instructeur de vol enseigne-t -il un ou plusieurs types de cours ?

Comme vous l'avez peut-être déjà deviné, vous pouvez également

utiliser cette question pour tester une relation d'auto-référencement en

apportant les mêmes modifications :

Un seul membre du personnel gère-t-il un ou plusieurs autres membres

du personnel ?

Utilisez le type de question que vous estimez le plus approprié pour la paire de

tables avec laquelle vous travaillez. Au fur et à mesure que vous parcourez la

liste des tableaux de la matrice, vous vous rendrez compte que vous posez

deux fois des questions sur une paire de tableaux donnée : une fois du point de

vue du premier tableau, puis de nouveau du point de vue du deuxième

tableau. Les réponses à ces deux questions identifieront le type de relation qui

existe entre les tables.

En continuant avec l'exemple, supposons que vous ayez décidé de commencer

par la table CLASSES et voici votre première question :

Un seul cours a-t-il lieu dans un ou plusieurs bâtiments ?

La réponse à cette question révélera le type de relation qui existe entre ces

tables du point de vue de la table CLASSES . Si vous recevez la réponse

suivante, alors une relation un-à-un existe entre ces tables :

Un seul cours a lieu dans un seul bâtiment.

Cependant, si vous recevez cette réponse, alors une relation un-à-

plusieurs existe entre les deux tables :

Un même cours peut avoir lieu dans plusieurs bâtiments.

Après avoir identifié la relation, indiquez le type de relation dans la case située

à la jonction de la ligne du tableau CLASSES (à gauche) et de la colonne du

tableau BÂTIMENTS (en haut). Vous pouvez utiliser les symboles abrégés

suivants pour les types de relation :

1:1 – un à un

1:N—un à plusieurs

M:N—plusieurs à plusieurs

Note

Vous n'aurez pas besoin du symbole abrégé plusieurs-à-plusieurs à ce stade,

mais je l'ai inclus ici par souci d'exhaustivité.

La figure 10.27 montre à quoi ressemble la matrice de table une fois que vous

avez fini d'identifier les relations pour la table CLASSES. N'oubliez pas que les

relations indiquées ici sont du point de vue du tableau CLASSES .

Figure 10.27 Entrées de table-matrice complétées pour la table CLASSES.

Vous avez probablement remarqué que certaines boîtes de jonction sont

vides ; c'est parfaitement acceptable. Entrer quoi que ce soit dans la boîte de

jonction estinutile s’il n’existe aucune relation entre les tables à chaque

extrémité de la jonction.

Maintenant, répétez ce processus pour chaque tableau du côté gauche de la

matrice. N'oubliez pas que vous pouvez commencer avec n'importe quelle

table. Supposons que vous décidiez de continuer avec la table BUILDINGS et

que vous tentiez d'identifier la relation entre celle-ci et la table CLASSES. Oui,

je sais que vous en avez déjà parlé une fois, mais dans ce cas, vous identifiez

la relation du point de vue de la table BUILDINGS . Supposons maintenant que

vous posiez cette question :

Un seul bâtiment offre-t-il de l’espace pour plus d’une classe ?

Si la réponse est « oui », alors une relation un-à-plusieurs existe entre ces

tables ; sinon, c'est une relation individuelle. Après avoir identifié la relation,

indiquez le type de relation dans la case située à la jonction de la ligne du

tableau BÂTIMENTS (à gauche) et de la colonne du tableau CLASSES (en

haut). La figure 10.28 montre la matrice du tableau révisé avec vos entrées

pour le tableau BUILDINGS.

Figure 10.28 Entrées de table-matrice complétées pour la table BUILDINGS.

Vous venez de voir deux exemples montrant comment identifier une relation

entre une paire de tables distincte. Voyons donc comment identifier une

relation d'auto-référencement pour une seule table. Supposons que vous

travaillez avec la table STAFF et que vous êtes maintenant à la jonction entre la

table STAFF de gauche et la table STAFF du haut. En utilisant letechniques que

vous avez apprises plus tôt dans cette section, vous pourriez poser une

question telle que celle-ci :

Un même membre du personnel peut-il être associé à un ou plusieurs autres

membres du personnel ?
Comme pour les exemples précédents, la réponse indiquera le type de

relation. Disons que vous avez reçu cette réponse :

Oui, un membre du personnel donné peut être le conjoint d'un autre membre

du personnel.

Cela indique (de manière assez évidente) qu'il existe une relation un-à-

un d'auto-référencement pour la table STAFF. Mais supposons que vous ayez

plutôt reçu cette réponse :

Oui, un seul collaborateur peut gérer plusieurs autres collaborateurs.

Vous avez probablement rapidement compris que cette réponse indique qu'il

existe une relation un-à-plusieurs d'auto-référence pour la table

STAFF. Identifier ces deux types de relations est une tâche relativement

facile ; identifier une relation plusieurs-à-plusieurs auto-référencée peut être

légèrement plus difficile.

C'est le type de question que vous devez poser pour déterminer si une table a

une relation plusieurs-à-plusieurs auto-référencée : une seule ( forme singulière

du nom de la table ) peut-elle être associée à un ou plusieurs autres ( forme

plurielle du nom de la table) ? nom de la table ), et l'un d'entre eux ( forme
plurielle du nom de la table ) peut-il alors être associé à un ou plusieurs autres
( forme plurielle du nom de la table ) ? Par exemple, voici une question que

vous pourriez poser pour la table STAFF :

Un seul membre du personnel peut-il être associé à un ou plusieurs autres

membres du personnel, et l'un de ces membres du personnel peut-il ensuite

être associé à un ou plusieurs autres membres du personnel ?

Une réponse telle que la suivante (ou une réponse très similaire) indique que la

table STAFF a une relation plusieurs-à-plusieurs auto-référencée :

Oui, un membre du personnel donné peut gérer plusieurs autres membres du

personnel, et n'importe laquelle de ces personnes peut alors superviser un ou

plusieurs autres membres du personnel.

Après avoir identifié le type de relation d'auto-référence qui existe pour la

table, vous l'indiquez dans la matrice du tableau comme vous le feriez pour

toute autre relation.

Les relations diffèrent souvent d’une perspective à l’autre, et vous devez savoir

déterminer quel type de relation existe officiellement entre chaque paire de

tables de la matrice. Vous effectuez cette détermination à l'aide de l'ensemble

de formules suivant : chaque formule correspond à une définition de type de

relation particulière. (J'ai fourni les définitions comme point de référence.)

1:1 + 1:1 = 1:1 Une paire de tables entretient une relation un-à-un lorsqu'un

seul enregistrement de la première table est lié à un seul enregistrement de la

deuxième table et à un seul enregistrement de la deuxième table. est lié à un

seul enregistrement de la première table.

1:N + 1:1 = 1:N Une relation un-à-plusieurs existe entre une paire de tables

lorsqu'un seul enregistrement de la première table peut être lié à un ou

plusieurs enregistrements de la deuxième table, mais qu'un seul

enregistrement dans la deuxième table ne peut être liée qu'à un

seul enregistrement de la première table.

1:N + 1:N = M:N Une paire de tables entretient une relation plusieurs-à-

plusieurs lorsqu'un seul enregistrement de la première table peut être lié à un

ou plusieurs enregistrements de la deuxième table et à un seul enregistrement

de la seconde. La table peut être liée à un ou plusieurs enregistrements de la

première table.
Voici la procédure spécifique que vous utiliserez pour identifier la relation

officielle entre une paire de tables de la matrice. (Il intègre les formules de

relation de la liste précédente.) Examinons d'abord une version générique de la

procédure.

1. Sélectionnez une paire de tables et notez l'entrée à la jonction entre la

première table et la deuxième table.

2. Localisez le deuxième tableau du même côté de la matrice sur laquelle vous

travaillez et notez l'entrée à la jonction entre celui-ci et le premier tableau

du côté opposé de la matrice.

3. Appliquez la formule appropriée aux deux entrées et identifiez la relation

officielle entre les tables.

4. Diagramme de la relation de la manière appropriée.

5. Rayez les deux entrées sur la matrice.

Voyons maintenant comment appliquer cette procédure à une paire de tables

de la matrice. (Dans cet exemple, vous travaillez sur le côté gauche de la

matrice.)

1. Supposons que vous ayez sélectionné les tables BÂTIMENTS et

CLASSES. Vous remarquez que l'entrée à la jonction entre BÂTIMENTS et

CLASSES est 1:N.

2. Maintenant, continuez sur le côté gauche de la matrice jusqu'à ce que vous

localisiez la table CLASSES, puis notez que l'entrée à la jonction entre la

table CLASSES et BUILDINGS est 1:1.

3. En utilisant ces entrées avec la formule appropriée, vous déterminez que la

relation officielle entre les tables BÂTIMENTS et CLASSES est 1:N. (1:N + 1:1

= 1:N)

4. Vous créez un diagramme de relations un-à-plusieurs pour les tables

BUILDINGS et CLASSES.

5. Vous rayez les entrées sur la matrice.

La figure 10.29 montre les résultats de votre travail.

Figure 10.29 Identification de la relation officielle entre les tables BÂTIMENTS

et CLASSES.

Notez que le diagramme de relations est construit du point de vue de la table

BUILDINGS. Cela est dû au fait que la table BUILDINGS se trouve du côté « un »

de la relation. Lorsque vous créez un diagramme simple comme celui-ci, je

vous recommande de toujours montrer le côté « un » duà gauche et le côté

« plusieurs » à droite. Suivre cette pratique rendra vos diagrammes faciles à

lire et vous aidera à garantir que vous les créez de manière cohérente. (Cette

pratique n'est toutefois pas nécessaire lorsque vous créez un diagramme

complexe montrant les relations entre plusieurs tables.)

À tout le moins, vous devez inclure la clé primaire de chaque table dans le

diagramme. Cela s’avérera être une aide visuelle précieuse lorsque vous

commencerez à établir les relations. Vous pouvez aller jusqu'à afficher la

structure complète de chaque table (comme vous le voyez sur la figure 10.30 ),

en supposant que vous disposez d'espace sur le diagramme. Afficher les

structures de cette manière contribue souvent à renforcer la décision que vous

avez prise concernant le type de relation qui existe entre les tables. (J'utilise les

deux types de diagrammes dans le reste du livre.)

Figure 10.30 Affichage de la structure de chaque table dans un diagramme

de relations.

Note

Vous aurez parfois du mal à identifier la relation exacte entre une paire de

tables donnée. Lorsque cela se produit, chargez simplement les tables avec des

exemples de données. Cela permet généralement de révéler le type de relation

qui existe entre les tables.

Il convient de mentionner que cette procédure est beaucoup plus simple et

plus courte lorsque vous travaillez avec une table ayant une relation d'auto-

référence, telle que la table STAFF. Comme l'illustre la figure 10.31 , tout ce que

vous avez à faire ici est de schématiser la relation et de rayer l'entrée sur la

matrice.

Figure 10.31 Travailler avec une relation d'auto-référencement.

Continuez cette procédure jusqu'à ce que vous ayez éliminé toutes les entrées

de la matrice. Lorsque vous avez fini d'identifier les relations officielles entre

les tables de la base de données, vous pouvez alors passer par le processus

d' établissement de chaque relation de la manière appropriée.

Établir chaque relation

Ce processus implique de définir une connexion logique explicite entre une

paire de tables liées. Le type de relation qui existe entre les tables détermine la

manière dont vous définissez la connexion.

Relations un-à-un et un-à-plusieurs

Vous utilisez une clé primaire et une clé étrangère pour établir la connexion

entre les tables participant à une relation un-à-un ou un-à-plusieurs. (Vous

apprendrez la définition d'une clé étrangère dans un instant.)

La relation individuelle

Dans ce type de relation, une table sert de table parent et l’autre de table

enfant. Un enregistrement doit exister dans la table parent avant que vous

puissiez saisir un enregistrement associé dans la table enfant ; Autrement dit,

un enregistrement dans la table enfant doit avoir un enregistrement associé

dans la table parent. Les rôles que vous attribuez aux tables dépendent

généralement des sujets qu'elles représentent, bien qu'il y ait des cas où vous

pourrez attribuer les rôles de manière plutôt arbitraire. Dans la figure 10.32 ,

par exemple, vous assignerez très probablement le rôle parent à la table STAFF

et le rôle enfant à la table COMPENSATION. Il s'agit d'une hypothèse

raisonnable car avoir un enregistrement dans la table RÉMUNÉRATION qui n'est

pas lié à un enregistrement dans la table PERSONNEL serait complètement

illogique.
Figure 10.32 Quelle table choisiriez-vous comme table parent ?

Dans le cas où l'une des tables est une table de sous-ensemble , vous

attribuerez généralement le rôle enfant à la table de sous-ensemble. Il existe

cependant des cas où vous pouvez attribuer le rôle parent à la table de sous-

ensemble.

Vous établissez une relation un-à-un en prenant une copie de la clé primaire de

la table parent et en l'incorporant dans la structure de la table enfant, où elle

devient alors une clé étrangère. (Le terme clé étrangère est dérivé du fait que

la table enfant possède déjà une clé primaire(elle est propre et la clé primaire

que vous introduisez à partir de la table parent est « étrangère » à la table

enfant.) Cependant, dans la plupart des relations un-à-un, la clé étrangère

sert également de clé primaire de la table enfant .

La figure 10.33 illustre comment établir la relation entre les tables STAFF et

FACULTY. STAFF est la table parent dans ce cas car un enregistrement de la

table FACULTY doit être lié à un enregistrement de la table STAFF ; les membres

du corps professoral sont issus du personnel de l'école. Si vous deviez suivre la

procédure que vous venez d'apprendre, vous prendriez une copie de la clé

primaire de la table STAFF et l'incorporerez comme clé étrangère dans la table

FACULTY. Cela n'est cependant pas nécessaire, car FACULTY est déjà une table

de sous-ensembles correctement définie. (Rappelez-vous qu'une table de sous-

ensemble et la table de données à partir de laquelle elle est dérivée doivent

partager la même clé primaire. Vous avez appris à définir une table de sous-

ensemble au chapitre 7 et à établir sa clé primaire au chapitre 8 , « Clés ».)

Figure 10.33 Établissement de la relation un-à-un entre les tables STAFF et

FACULTY.
La figure 10.34 montre un exemple légèrement différent de relation un-à-

un. Supposons que MANAGERS soit un sous-ensemble de table EMPLOYEES

mais qu'il ait une relation directe avec DEPARTMENTS : un seul manager est

associé à un seul département et un seul département est associé à un seul

département.associé à un seul gestionnaire. Supposons en outre que

MANAGERS est la table parent et DEPARTMENTS est la table enfant. (Il s'agit

d'un bon exemple de scénario dans lequel vous pouvez choisir les rôles de

manière plutôt arbitraire. C'est également un cas où une table de sous-

ensemble joue le rôle de parent au sein de la relation.)

Figure 10.34 Une relation un-à-un avec une table de sous-ensemble dans le
rôle parent.

Établissez la relation entre ces tables en utilisant la procédure que vous venez

d'apprendre, puis identifiez la nouvelle clé étrangère de la table DEPARTMENTS

(E MPLOYEE ID) en plaçant les lettres « FK » à côté de son nom. La figure

10.35 montre le diagramme de relation révisé avec les résultats de vos

modifications.
Figure 10.35 Établissement de la relation entre les tables MANAGERS et
DEPARTMENTS.

Tant que vous pouvez visualiser ce processus de manière générique, vous serez

en mesure d'établir n'importe quelle relation individuelle que vous

rencontrerez.

Note

De nombreux concepteurs de bases de données utiliseront M ANAGER ID comme

nom de clé primaire dans la table MANAGERS et comme nom de clé étrangère

dans la table DEPARTMENTS. J'ai choisi d'utiliser E MPLOYEE ID à la place pour ces

raisons.

• MANAGERS est un sous-ensemble de la table EMPLOYEES, il partage donc la

même clé primaire (E MPLOYEE ID).

• Il maintient le champ en conformité avec les éléments du champ idéal. (Il

conserve la majorité de ses caractéristiques lorsqu'il apparaît dans plus d'un

tableau.)
• Il maintient le champ conforme aux éléments d'une clé étrangère. (Vous en

apprendrez davantage sur les clés étrangères plus loin dans ce chapitre.)

• Cela supprime toute ambiguïté ou doute possible sur la véritable nature

d’une clé étrangère. (J'expliquerai cela plus en détail lors de la discussion

sur les éléments d'une clé étrangère.)

Il n’y a pas de bonne ou de mauvaise manière absolue de procéder. En fin de

compte, l’approche que vous utilisez est simplement une question de

style. Cependant, après avoir décidé quelle approche vous souhaitez utiliser,

assurez-vous de l’utiliser de manière cohérente.

Il y a un petit changement dans la façon dont vous schématiserez les relations

à partir de maintenant. Vous devez maintenant utiliser la clé primaire comme

point de départ et la clé étrangère comme point final de la ligne de relation. (La

seule exception sera lorsque vous schématisez la relation entre une table de

sous-ensemble et sa table de données parent.)cette modification mineure vous

aidera à visualiser plus clairement les relations et à identifier plus facilement

les champs qui établissent la relation.

La relation un-à-plusieurs

La technique que vous utilisez pour établir une relation un-à-plusieurs est

similaire à celle que vous avez utilisée pour établir une relation un-à-un. Il vous

suffit de prendre une copie de la clé primaire de la table du côté « un » de la

relation et de l'incorporer dans la structure de la table du côté « plusieurs », où

elle devient alors une clé étrangère. Par exemple, considérons la relation un-à-

plusieurs entre les tables BUILDINGS et ROOMS illustrées dans la figure 10.36 .
Figure 10.36 Relation un-à-plusieurs existante entre les tables BUILDINGS et
ROOMS.

La relation entre ces deux tables est telle qu'un seul bâtiment peut contenir

une ou plusieurs pièces, mais qu'une seule pièce est contenue dans un seul

bâtiment. À l'aide de la procédure décrite précédemment, vous établissez cette

relation en prenant une copie de la clé primaire (B UILDING N UMBER ) de la table

BUILDINGS et en l'incorporant en tant que clé étrangère dans la table

ROOMS. Maintenant, révisez le diagramme de relation et effectuez le même

type d'ajustements que vous avez fait avec le diagramme pour la relation un-à-

un. Votre diagramme révisé devrait ressembler à celui de la figure

10.37 . (Notez que la ligne médiane du symbole de la patte d'oie est le point de

connexion important : elle doit pointer directement vers la clé étrangère.)

Figure 10.37 Établissement de la relation un-à-plusieurs entre les BÂTIMENTS
et les PIÈCES.

Résolution des champs à valeurs multiples : revisitée

Au chapitre 7, vous avez appris comment résoudre un champ à plusieurs

valeurs en utilisant cette procédure générique :

1. Supprimez le champ de la table et utilisez-le comme base pour une nouvelle

table. Si nécessaire, renommez le champ conformément aux directives de

dénomination des champs que vous avez apprises plus tôt dans ce chapitre.

2. Utilisez un champ (ou un ensemble de champs) de la table d'origine pour

associer la table d'origine à la nouvelle table ; essayez de sélectionner des

champs qui représentent le plus fidèlement possible le sujet du

tableau. Le(s) champ(s) que vous choisissez apparaîtront dans les deux

tableaux.

3. Attribuez un nom, un type et une description appropriés à la nouvelle table

et ajoutez-la à la liste finale des tables.

Vous avez utilisé cette procédure pour résoudre un champ à plusieurs valeurs

appelé C ATEGORIES T AUGHT dans une table INSTRUCTORS. La figure

10.38 montre la version originale du tableau et les résultats de l'application de

la procédure.

Il existe un dernier fait concernant un champ à plusieurs valeurs que vous

devez apprendre : il existe une relation un-à-plusieurs inhérente entre un

ensemble donné de valeurs au sein d'un champ à plusieurs valeurs et

l'enregistrement dans lequel elles résident. Vous le verrez lorsque vous

examinerez la table INSTRUCTORS d'origine dans la figure 10.38 . Un seul

instructeur (comme Kira Bently) peut enseigner une ou plusieurs catégories

(DTP, SS, WP). Cela est vrai pour chaque enregistrement de la table.
Figure 10.38 La résolution originale du champ multivalué CATEGORIES ENSEIGNÉES .

Lorsque vous résolvez correctement le champ à plusieurs valeurs, les tables

produites par la procédure héritent de la relation. C’est clairement le cas des

tableaux révisés des INSTRUCTEURS et des nouveaux tableaux INSTRUCTEURS

DES CATÉGORIES. Vous pouvez maintenant établir cette relation un-à-plusieurs

comme vous le feriez pour n’importe quelle autre. (Bien entendu, cela suppose

que vous ayez attribué une clé primaire à la table INSTRUCTORS.) La figure

10.39 montre les résultats de l'établissement correct de cette relation.

Figure 10.39 Établissement de la relation un-à-plusieurs entre les tables
INSTRUCTEURS et INSTRUCTEURS CATEGORIES.

Le champ I NSTRUCTOR ID de la table INSTRUCTOR CATEGORIES sert de clé

étrangère et permet d'établir la relation un-à-plusieurs entre les tables

INSTRUCTORS et INSTRUCTOR CATEGORIES. I NSTRUCTOR ID fait également

partie de la clé primaire composite de la table INSTRUCTOR CATEGORIES ; une

combinaison donnée de valeurs I NSTRUCTOR ID et C ATEGORY T AUGHT identifie de

manière unique un enregistrement spécifique dans la table.

La relation plusieurs-à-plusieurs

Vous établissez une relation plusieurs-à-plusieurs avec une table de liaison . Il

s'agit d'un nouveau tableau que vous allez créer à l'aide de la procédure en

trois étapes suivante.

1. Définissez la table de liaison en prenant des copies de la clé primaire de

chaque table de la relation et en utilisant ces clés pour former la structure

de la table. Ces champs auront deux objectifs distincts au sein de la table de

liaison : ensemble, ils constituent la clé primaire composite de la table, et

chacun est une clé étrangère unique qui permet d'établir une relation entre

sa table parent et la table de liaison.

2. Donnez à la table de liaison un nom qui représente la nature de la relation

entre les deux tables. Par exemple, si vous établissez une relation plusieurs-

à-plusieurs entre une table PILOTS et une table CERTIFICATIONS, vous

pouvez choisir d'appeler la table de liaison PILOT CERTIFICATIONS.

3. Ajoutez la table de liaison à la liste finale des tables et effectuez les entrées

appropriées pour « Type de table » et « Description de la table ».

La figure 10.40 montre comment établir la relation plusieurs-à-plusieurs entre

les tables STUDENTS et CLASSES. (Notez le nouveau symbole de diagramme

utilisé pour représenter une table de liaison.)

Figure 10.40 Établissement de la relation plusieurs-à-plusieurs entre les
tables STUDENTS et CLASSES.

Note

Vous auriez pu utiliser STUDENT SCHEDULES ou CLASS SCHEDULES comme

nom de la table de liaison ; Il se trouve que les COURS POUR ÉTUDIANTS sont

ma préférence personnelle. Le point à retenir est que vous devez utiliser un

nom qui a le plus de sens pour vous ou pour l’organisation.

La création d'une table de liaison produit quelques résultats remarquables :

• La relation plusieurs-à-plusieurs d'origine a été dissoute car il n'existe plus

de relation directe entre les tables STUDENTS et CLASSES. La relation

d'origine a été remplacée par deux relations un-à-plusieurs : une entre

ÉTUDIANTS et CLASSES D'ÉTUDIANTS et une autre entre CLASSES et

CLASSES D'ÉTUDIANTS. Dans la première relation, un seul enregistrement

dans STUDENTS peut être associé à un ou plusieurs enregistrements dans

STUDENT CLASSES, mais un seul enregistrement dans la table STUDENT

CLASSES ne peut être associé qu'à un seul enregistrement dans

STUDENTS. Dans la deuxième relation, un seul enregistrement de la table

CLASSES peut être associé à un ou plusieurs enregistrements de STUDENT

CLASSES, mais un seul enregistrement de STUDENT CLASSES ne peut être

associé qu'à un seul enregistrement de STUDENT CLASSES.

• La table de liaison STUDENT CLASSES contient deux clés

étrangères. S TUDENT ID et C LASS ID sont tous deux des copies des clés

primaires des tables STUDENTS et CLASSES, respectivement ; par

conséquent, chacun est une clé étrangère par définition. En tant que tels, ils

aident à établir la relation entre leurs tables parentes et la table de liaison.

• La table de liaison STUDENT CLASSES possède une clé primaire composite

composée des champs Student ID et Class ID . Sauf dans de rares cas, une
table de liaison contient toujours une clé primaire composite. (Cette règle

s'applique uniquement à la conception logique de la base de données. Il

existe diverses raisons pour lesquelles vous pourriez enfreindre cette règle

lorsque vous transformez la conception logique en une conception physique,

mais cette discussion dépasse le cadre de ce livre.) Il est important de notez

que vous devrez occasionnellement ajouter plus de champs à la table de

liaison pour garantir une valeur de clé primaire unique. Par exemple,

supposons que l'école décide d'enregistrer les horaires des élèves pour

chaque trimestre de l'année scolaire (automne, hiver et printemps). Vous

devrez ajouter un nouveau champ, peut-être appelé T ERM , et le désigner

comme faisant partie de la clé primaire composite. Cela vous permettrait

d'entrer une autre instance d'un élève et d'une classe donnés dans le

tableau, mais pour un terme différent ; un étudiant peut devoir reprendre un

cours au trimestre de printemps parce qu’il a échoué au cours du

trimestre d’automne .

• La table de liaison permet de limiter les données redondantes au minimum

absolu. Il n'y a aucune donnée superflue dans ce tableau. En fait, le

principal avantage de cette structure de tableau est qu'elle vous permet de

saisir autant de classes que nécessaire pour un seul élève. Plus tard dans le

processus de conception de base de données, vous apprendrez à créer des

vues pour rassembler les données de ces tables afin de les présenter sous

forme d'informations significatives.

• Le nom de la table de liaison reflète l'objectif de la relation qu'elle contribue

à établir. Les données stockées dans la table STUDENT CLASSES

représentent un élève et les classes dans lesquelles il est inscrit.
Lorsque vous travaillez avec des relations plusieurs-à-plusieurs, vous devrez

parfois ajouter des champs à la table de liaison pour réduire la redondance des

données et affiner davantage les structures des tables participant à la

relation. Par exemple, supposons que vous travaillez sur une nouvelle base de

données avec un collègue et qu'il vient de porter à votre attention les tables

ORDERS et PRODUCTS de la figure 10.41 .

Figure 10.41 Y a-t-il un problème avec l'une ou l'autre de ces tables ?

Vous remarquez qu'il existe une relation plusieurs-à-plusieurs entre les tables,

puis réalisez que votre collègue a essayé d'établir cette relation en prenant une

copie des champs NUMÉRO DE PRODUIT et PRIX DE DEVIS de la table PRODUITS et

en les incorporant dans le champ PRODUITS. Tableau COMMANDES. Il pensait

que c'était la meilleure façon d'associer différents produits à une commande

particulière. La présence de ces champs dans la table ORDERS produit

cependant une grande quantité de données redondantes. La figure

10.42 illustre assez clairement ce problème.

Figure 10.42 Données redondantes causées par une relation plusieurs-à-
plusieurs mal établie.

Vous ne pouvez saisir qu'un seul numéro de produit, une seule quantité

commandée et un seul prix proposé pour un enregistrement donné ; par

conséquent, vous devrez saisir un nouvel enregistrement dans le tableau pour

chaque article qu'un client place sur sa commande. Le client numéro 9001, par

exemple, comprenait huit articles sur une commande qu'il a passée le 16 mai.

Il y a donc huit enregistrements dans le tableau pour cette seule commande.

D’après ce que vous avez appris plus tôt dans ce chapitre, vous savez qu’il

s’agit d’une manière inappropriée d’établir cette relation. Vous savez

également que vous pouvez établir correctement la relation en créant et en

utilisantune table de liaison. Vous supprimez donc le champ

NUMÉRO DE PRODUIT de la table COMMANDES, établissez la relation de la

manière appropriée et révisez le diagramme de relation. La figure

10.43 montre les résultats de votre travail.

Figure 10.43 Établir correctement la relation plusieurs-à-plusieurs entre les
tables ORDERS et PRODUCTS.

Vous avez éliminé les données redondantes de la table ORDERS, mais vous

rencontrez toujours deux problèmes mineurs.

1. Les champs DEVIS P RICE et Q UANTITY O RDERED ne sont plus appropriés pour la

table COMMANDES ; la clé primaire de la table ORDERS n'identifie pas

exclusivement leurs valeurs et elles n'ont aucun rapport avec les autres

champs de la table. Ils se rapportent cependant à un NUMÉRO DE PRODUIT

particulier qui fait partie d'une commande donnée dans la table DÉTAILS DE LA

COMMANDE.

2. Vous avez des données en double car il existe deux copies du champ

Q UOTE P RICE : une dans la table ORDERS et une autre dans la table

PRODUCTS.
Ainsi, vous résolvez le premier problème en supprimant les champs

Q UOTE P RICE et Q UANTITY O RDERED de la table ORDERS et en les incorporant

dans la table ORDER DETAILS. Vous résolvez ensuite le deuxième problème en

supprimant le champ Q UOTE P RICE de la table PRODUCTS ; il est plus logique

d'associer un prix devis à un produit au fur et à mesure de sa

commande. Enfin, vous modifiez le diagramme de relations pour refléter les

modifications que vous avez apportées aux structures. La figure 10.44 montre

votre diagramme révisé.

Figure 10.44 Tableau de liaison révisé DETAILS DE LA COMMANDE.

Lorsque vous établissez une relation plusieurs-à-plusieurs entre une paire de

tables, assurez-vous de vérifier chaque table et de déterminer s'il existe des

champs que vous devez transférer vers la table de liaison. En cas de doute,

chargez tous les tableaux avec des exemples de données ; cela révélera

généralement tout problème potentiel.

Note
Vous ne rencontrerez pas ce problème très souvent si vous suivez fidèlement le

processus de conception que vous avez appris jusqu'à présent. Cependant,

cela se produit généralement lorsque vous essayez d'incorporer une paire de

tables à partir d'une base de données existante ou d'une base de données

héritée et que vous n'avez pas pris le temps d'affiner correctement leurs

structures. Vous rencontrerez également ce problème lorsque vous travaillerez

avec quelqu'un qui a peu ou pas d'expérience en conception de bases de

données.

Relations d'auto-référencement

Établir une relation d'auto-référencement sera une tâche relativement simple

maintenant que vous savez comment établir une relation entre une paire de

tables.

Un à un et un à plusieurs

Vous utilisez une clé primaire et une clé étrangère pour établir des relations un-

à-un et un-à-plusieurs auto-référencées, tout comme vous le faites avec leurs

homologues à double table. La différence ici, cependant, est que la clé

étrangère résidera dans la même table que la clé primaire à laquelle elle fait

référence. Vous constaterez souvent que la clé étrangère fait déjà partie de la

structure de la table. Si la clé étrangère n’existe pas déjà, vous en créerez

simplement une.
Reprenons l'exemple de la table MEMBERS de la figure 10.20 . Rappelons que

cette table a une relation un-à-un d'auto-référence car un membre donné ne

peut parrainer qu'un seul autre membre au sein de l'organisation ; le champ ID

S PONSOR stocke le numéro d'identification du membre agissant en tant que

sponsor. Étant donné que le champ S PONSOR ID tire ses valeurs exclusivement

du champ M EMBER ID, il agit comme la clé étrangère de la relation. Vous

établissez la relation en désignant officiellement le champ S PONSOR ID comme

clé étrangère et en le notant comme tel dans le diagramme de relation. La

figure 10.45 montre le diagramme de relation révisé pour la table MEMBERS.

Figure 10.45 Établissement de la relation un-à-un d'auto-référencement pour

la table MEMBERS.

Considérons maintenant l'exemple de la table STAFF de la figure 10.46 . Vous

vous souvenez peut-être que cette table a une relation un-à-plusieurs auto-

référencée, car un seul membre du personnel peut gérer un ou plusieurs autres

membres du personnel.
Figure 10.46 La structure actuelle de la table STAFF.

Actuellement, aucun moyen n'existe pour associer un membre du personnel

donné à d'autres membres du personnel au sein du tableau ; par conséquent,

vous devez créer un nouveau champ qui fera office de clé étrangère et vous

permettra d'établir la relation. Supposons que vous créiez un nouveau champ

de clé étrangère appelé M ANAGER IDqui tirera ses valeurs exclusivement du

champ S TAFF ID. Vous établissez maintenant la relation en désignant

officiellement M ANAGER ID comme clé étrangère et en la notant comme telle

dans le diagramme de relation. La figure 10.47 montre le diagramme de

relation révisé pour la table STAFF.

Figure 10.47 La table STAFF révisée avec la nouvelle clé étrangère MANAGER ID.

Vous avez probablement remarqué que le côté « un » de la ligne de relation

pointe vers le champ ID DU GÉRANT et que le côté « plusieurs » de la ligne pointe

vers le champ ID DU PERSONNEL . Ceci est parfaitement acceptable car un

manager va gérer un ou plusieurs membres du personnel, mais un membre du

personnel donné ne rapporte qu'à un seul manager. (Comme vous l'avez peut-

être initialement supposé intuitivement, généralement le côté « un » de la

ligne pointe vers la clé primaire et le côté « plusieurs » vers la clé étrangère.

Dans ce cas, cependant, l'inverse est vrai.)

Pendant que vous travaillez avec des relations un-à-un et un-à-plusieurs auto-

référencées, prenez un moment et examinez attentivement la structure de

chaque table. Vous constaterez occasionnellement que vous pouvez (ou

devrez) modifier et améliorer la structure existante pour éliminer la relation. Je

sais ce que vous vous demandez : « Mais pourquoi voudrais-je faire ça ? »

Récupérer des informations à partir de tables comportant ces types de

relations peut être fastidieux et quelque peu difficile. (Une discussion sur les

raisons de cela sort malheureusement du cadre de ce travail.) De plus, la

présence même de la relation peut indiquer la nécessité de nouvelles

structures de champs et de tables.

Considérez à nouveau la table STAFF. Vous vient-il à l’esprit que s’il est

nécessaire de suivre les membres du personnel qui sont des managers, il

pourrait être nécessaire de suivre les départements qu’ils dirigent ? Si cela est

vrai, il doit y avoir d'autres facettes des départements que vous devez suivre

dans la base de données. Vous devez maintenant mener un entretien rapide

avec les membres du personnel concernés pour répondre à ces questions, puis

prendre les mesures appropriées en fonction de leurs réponses.

Supposons que vous aviez raison et que l'organisation souhaite suivre les

données des départements. La figure 10.48 montre une approche possible que

vous pourriez utiliser pour accomplir cette tâche.

Figure 10.48 Résultats de l'élimination de la relation d'auto-référencement et

de l'ajout de nouvelles structures pour suivre les données ministérielles.
Ces nouvelles structures et relations vous permettront de suivre efficacement

les données et fourniront une grande variété d'informations sur les

départements. (Vous veillerez bien entendu à ce que les nouveaux champs et

tables soient conformes aux différents éléments de conception que vous avez

appris jusqu'à présent.)

Il est important de noter que les relations d’auto-référencement ont leur place

dans une base de données bien conçue. Il faudra cependant être vigilantet

assurez-vous que chaque relation d'auto-référencement sert effectivement un

objectif utile.

Plusieurs à plusieurs

Vous utilisez une table de liaison pour établir une relation plusieurs-à-plusieurs

auto-référencée, tout comme vous le faites avec son homologue à double

table. L'établissement de cette relation est légèrement différent dans la mesure

où les champs que vous utilisez pour créer la table de liaison proviennent de la

même table parent.

Reprenons l'exemple de table PARTS de la figure 10.24 . Rappelez-vous que ce

tableau a une relation plusieurs-à-plusieurs auto-référencée, car une partie

particulière peut comprendre plusieurs composants différents, et cette partie

elle-même peut être un composant d'autres parties. Vous établissez cette

relation comme vous le feriez pour toute autre relation plusieurs-à-plusieurs :

avec une table de liaison. Actuellement, il n'existe aucun moyen d'associer une

pièce donnée à d'autres pièces au sein de la table, vous devez donc créer un

nouveau champ à cet effet. Supposons, par exemple, que vous créiez un

champ appelé ID COMPOSANT . Ce champ stockera le numéro d'identification

d'une pièce qui sert de composant à une pièce parent. Vous pouvez désormais

utiliser les champs P ART ID et C OMPONENT ID comme base pour la table de

liaison. Pour les besoins de notre exemple, nous supposerons que le nom de la

nouvelle table de liaison est PART COMPONENTS. Après avoir créé et nommé la

table de liaison, veillez à réviser le diagramme de relations de la table

PARTS. La figure 10.49 montre les résultats de votre travail.

Figure 10.49 Établissement de la relation plusieurs-à-plusieurs d'auto-

référencement pour la table PARTS.
Comme vous pouvez le constater, la table PARTS a désormais deux relations

un-à-plusieurs distinctes avec la table PART COMPONENTS. La première relation

est établie via le champ P ART ID, et la seconde relation est établie via le champ

C OMPONENT ID. La figure 10.50 illustre le fonctionnement de ces relations. Notez

qu'un ensemble de serrage (ID de pièce 704) contient trois composants et est

lui-même un composant d'un ensemble de siège (ID de pièce 707) et d'un

ensemble de cadre (ID de pièce 711).

Figure 10.50 Relations de données entre les tables PARTS et PART

COMPONENTS.

Maintenant, utilisez les techniques que vous venez d'apprendre pour établir

toutes les relations que vous avez identifiées entre les tables de la base de

données. Assurez-vous absolument de créer un diagramme pour chaque

relation ; vous allez ajouter de nouvelles informations à ces diagrammes au fur

et à mesure que le processus de conception se déroulera.

Examen de la structure de chaque table

Passez en revue toutes les structures de table après avoir établi les relations

entre les tables. N'oubliez pas que vous avez apporté des modifications aux

structures de tables existantes et créé plusieurs nouvelles structures de tables

au fur et à mesure que vous établissiez les relations ; par conséquent, vous

voulez vous assurer que chaque table est conforme aux éléments de la table

idéale.

Éléments de la table idéale

• Il représente un sujet unique, qui peut être un objet ou un événement.

• Il possède une clé primaire.

• Il ne contient pas de champs en plusieurs parties ou à valeurs multiples.

• Il ne contient pas de champs calculés.

• Il ne contient pas de champs en double inutiles.

• Il ne contient qu’un minimum absolu de données redondantes.

Lorsque vous déterminez qu'un tableau n'est pas conforme aux éléments du

tableau idéal, identifiez le problème et apportez les modifications

nécessaires. Ensuite, parcourez le tableau à travers les étapes appropriées du

processus de conception de base de données jusqu'à ce que vous reveniez à ce

point. Vous ne devriez rencontrer aucun problème avec les tables si vous avez

suivi les procédures appropriées jusqu'à présent.

Affiner toutes les clés étrangères

Vous savez maintenant qu'une clé primaire devient une clé étrangère lorsque

vous l'utilisez pour établir une relation entre une paire de tables dans une

relation un-à-un ou un-à-plusieurs. Comme pour toute autre clé avec laquelle

vous avez travaillé jusqu'à présent, une clé étrangère doit être conforme à un

ensemble spécifique d'éléments. Ces éléments sont collectivement connus

sous le nom d’éléments d’une clé étrangère.

Éléments d'une clé étrangère

• Elle porte le même nom que la clé primaire à partir de laquelle elle a été

copiée. Vous devez respecter cette règle à moins qu’il n’existe une raison
absolument impérieuse de ne pas le faire. (Revoyez la discussion sur

l'élément de spécification de champ Alias au chapitre 9 , « Spécifications de

champ ». Il fournit un exemple d'occasion où vous pourriezdécidez

d'enfreindre cette règle.) Considérez le diagramme de relations de la figure

10.51 et notez que les clés étrangères ont des noms différents de ceux des

clés primaires auxquelles elles font référence.

Figure 10.51 Clés primaires et clés étrangères avec des noms

incompatibles.
Le fait que les noms soient différents pose problème car on ne peut pas être

sûr que les clés étrangères sont réellement valides et font réellement

référence aux clés primaires. Le numéro E MP est -il vraiment équivalent

au NUMÉRO D' EMPLOYÉ ? « Emp » est-il vraiment une version abrégée de «

Employé » ou cela signifie-t-il autre chose ? Pourquoi quelqu'un a-t-il choisi

d'utiliser le numéro C LIENT dans la table COMMANDES au lieu de

l'ID CLIENT ? Y a-t-il une différence entre les deux? Stockent-ils le même type

de données ? Vous devez répondre à ces questions avant de pouvoir faire

quoi que ce soit d'autre avec ces tables et leurs relations respectives.

Vous pourriez faire valoir un argument relativement raisonnable selon lequel

les noms sont suffisamment proches pour supposer que les clés étrangères

sont effectivement valides. En cas de doute, vous pouvez tester votre

hypothèse en chargeant les tableaux avec des exemples de

données. Cependant, vous ne devriez vraiment pas avoir à prendre le temps

de le faire. Imaginez devoir faire cela pendant 15 ou 20 relations ; la

quantité de temps perdu s’additionne.

Vous n’aurez pas du tout à poser ces questions ni à effectuer ces tests

lorsque vous adhérerez à cet élément. La figure 10.52 montre une version

révisée du diagramme qui utilise les noms de clés étrangères

appropriés. Dans ce cas, il n’y a aucune ambiguïté et il ne fait aucun doute

queles clés étrangères sont appropriées. Vous pourrez examiner ce

diagramme dans neuf mois et, d'un simple coup d'œil, déterminer en toute

confiance le type de relations entre les tables et la manière dont elles sont

établies.
Figure 10.52 Clés étrangères conformes au premier élément d'une clé
étrangère.

Note

Je rencontre ce problème assez souvent lorsqu'on me demande d'analyser

certains types de problèmes de bases de données. Dans de nombreux cas,

les clés étrangères sont soit totalement inappropriées, soit manifestent de

graves problèmes d’intégrité des données et des relations. Après avoir

identifié les clés étrangères appropriées (ou révisé celles existantes) et

vérifié qu'elles respectent cet élément particulier, un certain nombre de

problèmes disparaissent.

La seule fois où je peux justifier et approuver l’utilisation d’un nom différent

pour le champ de clé étrangère, c’est lorsque j’établis une relation d’auto-

référence pour une table donnée. Cela est raisonnable car la clé primaire et

la clé étrangère résident toutes deux dans la table (dans la plupart des cas)

et chacune doit avoir un nom unique.

• Il utilise une réplique des spécifications de champ pour la clé primaire à

partir de laquelle elle a été copiée. Cela prend en charge le sixième élément
d'un champ idéal, que vous avez appris au chapitre 7 (« Il conserve la

majorité de ses propriétés lorsqu'il apparaît dans plus d'un tableau »). Une

clé étrangère, cependant, possède quelques paramètres dans les éléments

générauxet les catégories d'éléments logiques légèrement différentes de

celles de sa clé primaire parente.

Vous modifierez quatre éléments dans la catégorie Éléments généraux

lorsque vous définirez une spécification de champ pour une clé étrangère :

1. Type de spécification : étant donné qu'une clé étrangère est basée sur

une clé primaire existante, elle hérite d'une réplique des spécifications de

champ de la clé primaire ; par conséquent, vous désignez le type de

spécification de la clé étrangère comme « Réplique ». Cette désignation

vous aide à garantir que les spécifications de votre clé étrangère sont

cohérentes et vous rappelle de garder cette spécification synchronisée

avec la spécification de la clé primaire.

2. Table parent : le nom de la table parent de la clé étrangère est placé ici.

3. Spécification source : c'est ici que vous indiquez le nom de la clé primaire

parent. (Assurez-vous d'inclure également le nom de la table parent de la

clé primaire ; cela vous permettra de trouver plus facilement la

spécification de la clé primaire si vous souhaitez la comparer à la

spécification de la clé étrangère.)

4. Description : rédigez une description indiquant l'objectif de la clé

étrangère dans le tableau. La figure 10.53 montre un exemple de ces

modifications pour un champ EMPLOYEE ID N UMBER servant de clé étrangère

dans une table ORDERS.

Figure 10.53 Éléments généraux pour le champ de clé étrangère
E MPLOYEE ID N UMBER dans la table ORDERS.

Vous allez également ajuster cinq éléments de la catégorie Éléments

logiques pour la spécification du champ de clé étrangère :

5. Type de clé : définissez cet élément sur « Étranger ». Il s’agit d’un

changement plutôt évident, mais que vous pouvez accidentellement

ignorer si vous n’y faites pas attention.

6. Unicité : vous désignez cet élément comme « Non unique » car vous

souhaitez pouvoir associer une seule valeur de clé étrangère à n'importe

quel nombre d'enregistrements dans la table parent. Dans notre

exemple, vous souhaitez pouvoir associer un employé spécifique à

n'importe quel nombre de commandes. Si vous le définissez plutôt sur

« Unique », vous pourriez associer un employé donné à une seule

commande, ce qui limiterait grandement son potentiel de vente ! (Dans

le cas d'une relation un-à-un , cependant, vous désignerez cet élément

comme « Unique » car vous souhaitez associer une seule valeur de clé

étrangère dans la table enfant à un seul enregistrement dans la table

parent.)

7. Valeurs entrées par : contrairement à la clé primaire parent, vous (ou un

utilisateur) entrerez des valeurs dans la clé étrangère ; par conséquent,

vous définissez cet élément sur « Utilisateur ».

8. Plage de valeurs : vous devez définir cet élément de telle manière que

vous (ou un utilisateur) puissiez saisir uniquement les valeurs existantes

de la clé primaire parent. (Vous en apprendrez davantage à ce sujet et

verrez un bon exemple dans un instant.)

9. Règle de modification : vous définissez normalement cette valeur sur

"Entrer maintenant, modifications autorisées", bien qu'il puisse y avoir

des cas (par exemple lorsque la clé étrangère provient d'une table de

validation) où vous pouvez définir cette valeur sur "Entrer plus tard,

modifications autorisées". Autoriser la modification des valeurs de clé

étrangère vous permet de corriger les erreurs. Par exemple, vous avez

peut-être saisi par erreur le numéro d'identification d'employé « 100 »

pour une commande donnée alors que vous vouliez saisir « 110 ».

La figure 10.54 montre un exemple de ces modifications pour le champ de

clé étrangère E MPLOYEE ID N UMBER . (Notez le paramètre de plage de

valeurs : c'est un bon moyen de définir cet élément.)

Figure 10.54 Éléments logiques pour le champ de clé étrangère E MPLOYEE ID

N UMBER dans la table ORDERS.

Afin que vous puissiez voir l'importance de ces modifications, la figure

10.55 montre la catégorie Éléments logiques de la spécification

source. (Rappelez-vous que cet élément fait partie de la catégorie Éléments

généraux ; reportez-vous à la figure 10.53 .)

 Figure 10.55 Éléments logiques pour le champ de clé primaire E MPLOYEE ID
N UMBER dans la table EMPLOYEES.

• Il tire ses valeurs de la clé primaire à laquelle il se réfère. Par définition, la

plage de valeurs d'une clé étrangère est limitée aux valeurs existantes de la

clé primaire à laquelle elle fait référence. Par exemple, vous ne pouvez pas

saisir un NUMÉRO D'ID D' EMPLOYÉ non valide dans la table

COMMANDES. Tout NUMÉRO D'ID D' EMPLOYÉ que vous entrez dans la table

COMMANDES doit d'abord exister en tant que NUMÉRO D' ID D' EMPLOYÉ dans la

table EMPLOYEES. Cela garantit la cohérence entre les valeurs des deux

champs dans les deux tables et contribue à établir l'intégrité au niveau des

relations.

Examinez les clés étrangères de chaque table pour vous assurer qu'elles sont

conformes aux éléments d'une clé étrangère et apportez les modifications

appropriées à celles qui ne le font pas. Vous ne devriez vraiment rencontrer

aucun problème si vous avez suivi fidèlement le processus de conception

jusqu'à présent.
Établir les caractéristiques de la relation

Vous allez maintenant établir les caractéristiques de chaque relation. Ces

caractéristiques indiquent ce qui se passe lorsque vous supprimez un

enregistrement, le type de participation de chaque table dans la relation et le

degré de participation de chaque table à la relation.

Définir une règle de suppression pour chaque relation

La première caractéristique que vous établirez pour la relation est une règle de

suppression . Cette règle détermine ce que votre SGBDR doit faire lorsque vous
effectuez une demande de suppression d'un enregistrement donné dans la

table parent de la relation. Les règles de suppression sont cruciales pour

l'intégrité au niveau des relations, car elles permettent de se prémunir contre

les enregistrements orphelins , c'est-à-dire les enregistrements de la table

enfant qui n'ont aucune relation avec les enregistrements de la table parent.

Voici les cinq types de règles de suppression que vous pouvez définir et les

actions que le SGBDR doit entreprendre lorsqu'une règle donnée est en

vigueur :

1. Refuser : le SGBDR ne supprimera pas l'enregistrement dans la table parent,

mais conservera l'enregistrement et le désignera comme « inactif ».

2. Restreindre : le SGBDR ne supprimera pas l'enregistrement dans la table

parent si des enregistrements associés existent dans la table enfant. Vous

devez demander au SGBDR de supprimer tous les enregistrements associés

dans la table enfant avant de pouvoir lui demander de supprimer

l'enregistrement dans la table parent.

3. Cascade : le SGBDR effectuera deux actions spécifiques : il supprimera

l'enregistrement dans la table parent et il supprimera également

automatiquement tous les enregistrements associés dans la table enfant.

4. Annuler : le SGBDR supprimera l'enregistrement dans la table parent et

mettra ensuite à jour les valeurs de clé étrangère des enregistrements

associés dans la table enfant sur Null. Si vous envisagez d'utiliser cette

règle de suppression, vous devez modifier les spécifications du champ de la

clé étrangère et définir l'élément logique Null Support sur « Nulls Allowed ».

5. Définir par défaut : le SGBDR supprimera l'enregistrement dans la table

parent et mettra ensuite à jour les valeurs de clé étrangère des

enregistrements associés dans la table enfant avec une valeur par défaut

spécifiée que vous avez définie dans le SGBDR. Évidemment, vous devez

définir une valeur par défaut pour utiliser cette règle.

Utilisez une règle Restreindre la suppression systématiquement et les autres

règles le cas échéant. La meilleure façon de déterminer quelle règle de

suppression est appropriée pour une relation donnée consiste à examiner le

diagramme de relation. Considérez le diagramme de la figure 10.56 .

Figure 10.56 Quelle règle de suppression est appropriée pour une relation
donnée ?

Sélectionnez une relation, regardez le diagramme et posez la question

suivante :

Lorsqu'un enregistrement de la table ( nom de la table parent ) est supprimé,

que doit-il arriver aux enregistrements associés dans la table ( nom de la table

enfant ) ?
Ici, la question est formulée de manière générique afin que vous puissiez

comprendre le principe qui la sous-tend. Lorsque vous posez cette question

pour une paire de tables dans une relation particulière, remplacez les

expressionsentre parenthèses avec les noms de table appropriés. Si vous

travaillez avec la relation entre les tables EMPLOYEES et ORDERS, vous pouvez

poser la question de cette manière :

Lorsqu'un enregistrement de la table EMPLOYEES est supprimé, que doit-il

arriver aux enregistrements associés dans la table ORDERS ?

La réponse que vous recevez dépend de la manière dont l'organisation utilise

les données contenues dans les tables et indiquera généralement la règle de

suppression que vous devez utiliser pour la relation.

Vous ne pouvez pas supprimer un dossier d'employé ; vous devez désigner le

salarié comme inactif. (Utilisez une règle de refus .)

Vous ne pouvez pas supprimer un enregistrement d'employé s'il existe des

enregistrements de commande associés. (Utilisez une règle de restriction .)

Vous devez d'abord supprimer les commandes associées à l'employé de la

table ORDERS, puis supprimer l'employé de la table EMPLOYEES. (Utilisez la

règle Restreindre .)

Toutes les commandes associées à l'employé doivent également être

supprimées de la table ORDERS. (Utilisez la règle de la Cascade .)

Le numéro d'employé pour toutes les commandes associées à l'employé doit

être supprimé. (Utilisez une règle Nullify .)

Le numéro d'employé de toutes les commandes associées à l'employé doit être

réinitialisé au numéro d'employé du vendeur principal. (Utilisez une

règle Définir par défaut .)

Si vous (ou les personnes avec lesquelles vous travaillez) ne parvenez pas

facilement à fournir une réponse, prenez note de la relation et poursuivez une

autre relation. Vous reverrez toutes ces relations lorsque vous établirez des

règles métier pour la base de données au chapitre 11 , « Règles métier ». Pour

l'instant, supposons que vous avez reçu la première réponse et que vous allez

utiliser une règle de refus pour la relation.

Après avoir identifié le type de règle de suppression que vous souhaitez utiliser

pour la relation, désignez la règle sur le diagramme de relation. Utilisez (D)

pour Refuser, (R) pour Restreindre, (C) pour Cascade, (N) pour Annuler et (S)

pour Définir par défaut. Placez la désignation sous la ligne de connexion de la

table parent . La figure 10.57 montre le diagramme de relation révisé pour les

tables EMPLOYEES et ORDERS.

Figure 10.57 Désignation d'une règle de refus de suppression pour la relation

entre les tables EMPLOYEES et ORDERS.
Vous définissez toujours la règle de suppression du point de vue de la table

parent, car il s'agit de la plus importante des deux tables au sein de la

relation. La suppression d'un enregistrement dans la table parent aura toujours

un certain effet sur les enregistrements associés dans la table enfant, mais la

suppression d'un enregistrement dans la table enfant aura peu ou pas d'effet

sur l'enregistrement associé dans la table parent. (Il existe une circonstance

spécifique pour laquelle vous souhaiterez peut-être établir une règle de

restriction de suppression pour la table enfant, et vous en apprendrez

davantage au chapitre 11. )

La question que vous utilisez pour déterminer la règle de suppression pour une

relation d'auto-référencement est légèrement différente de celle que vous

venez d'utiliser pour une relation à double table :

Lorsqu'un enregistrement de la table ( nom de la table parent ) est supprimé,

que doit-il arriver aux valeurs de clé étrangère des autres enregistrements qui

lui étaient associés ?

Si vous travaillez avec la relation d'auto-référence pour la table EMPLOYEES,

vous pouvez poser la question de cette manière :

Lorsqu'un enregistrement de la table EMPLOYEES est supprimé, que doit-il

arriver aux valeurs de clé étrangère des autres enregistrements qui lui étaient

associés ?

Encore une fois, la réponse indiquera généralement quelle règle de suppression

vous devez utiliser pour la relation :

Vous ne pouvez pas supprimer un enregistrement pour un employé qui gère

actuellement d'autres employés. (Utilisez une règle de restriction .)

Si l'employé que vous souhaitez supprimer est un manager, vous ne pouvez

pas supprimer son enregistrement tant que vous n'avez pas affecté les

employés qu'il gère à un autre manager. (Utilisez la règle Restreindre .)

Si l'employé dont vous souhaitez supprimer l'enregistrement est un

gestionnaire, l' ID MANAGER doit être supprimé de l'enregistrement de chaque

employé qu'il gère actuellement. (Utilisez une règle Nullify .)

Si l'employé dont vous souhaitez supprimer l'enregistrement est un

gestionnaire, l'ID DU GÉRANT doit être réinitialisé au numéro d'employé du

cadre supérieur dans l'enregistrement de chaque employé qu'il gère

actuellement. (Utilisez une règle Définir par défaut .)

Note

La règle Cascade est notamment absente de cet exemple car elle ne s'applique

pas du tout à la relation ; vous ne voulez pas licencier des employés

simplement parce que leur manager quitte l'organisation. Cette règle reste une

option viable dans certains cas, alors gardez-la à l'esprit lorsque vous

établissez des règles de suppression pour d'autres relations d'auto-

référencement.

Supposons que vous ayez reçu la dernière réponse de la liste précédente et

que vous ayez déterminé que vous allez utiliser une règle de suppression

Définir par défaut pour la relation. Vous terminez maintenant le processus en

désignant la règle sur le diagramme de relations. La figure 10.58 montre les

résultats de votre travail.

Figure 10.58 Désignation d'une règle de suppression Définir par défaut pour
la relation d'auto-référencement de la table EMPLOYEES.

Identifier le type de participation pour chaque table

Lorsque vous établissez une relation entre deux tables, chaque table participe

d'une manière particulière. Le type de participation que vous attribuez à une

table donnée détermine si un enregistrement doit exister dans cette table

avant que vous puissiez saisir des enregistrements dans la table associée. Les

deux types de participation sont :

1. Obligatoire : au moins un enregistrement doit exister dans cette table avant

que vous puissiez saisir des enregistrements dans la table associée.

2. Facultatif : Il n'est pas nécessaire que des enregistrements existent dans

cette table avant de pouvoir saisir des enregistrements dans la table

associée.

Vous déterminerez généralement le type de participation pour la plupart des

tables plus tard lorsque vous définirez les règles métier, bien que vous puissiez

très souvent établir le type de participation pour les tables dans des relations

où le type de participation pour chaque table est évident, est le résultat de

relève du bon sens ou est conforme à un ensemble particulier de normes. Par

exemple, considérons la relation un-à-plusieurs entre les tables EMPLOYEES et

CUSTOMERS dans la figure 10.59 . (Il s'agit de versions légèrement différentes

des tableaux de la figure 10.56 .)

Figure 10.59 Quel type de participation devez-vous attribuer à chaque table ?

Supposons que chaque client doit être attribué à un employé particulier. Cet

employé agit en tant que représentant du compte du client et s'occupe de

toutes les transactions et communications entre l'organisation et ce client. Bien

que chaque client doive être associé à un employé particulier, un employé

donné ne doit pas nécessairement être associé à un client. De nombreux

employés exercent d'autres fonctions au sein de l'organisation qui ne

nécessitent pas d'interaction avec les clients.

Ce scénario n'implique ni ne définit de circonstances particulières mais indique

la manière dont l'organisation mène cette partie de ses activités. En tant que

tel, vous pouvez déduire ce qui suit.

• Vous devez désigner un type de participation obligatoire pour le tableau

EMPLOYÉS. Cela garantit que vous avez au moins un employé à affecter à

un client donné.

• Vous devez désigner un type de participation facultatif pour la table

CLIENTS. Cela vous permet d'inscrire toute personne employée par

l'organisation.
Après avoir déterminé le type de participation de chaque table au sein de la

relation, désignez la participation de chaque table sur le diagramme de

relation. Utilisez une ligne verticale pour représenter un type de participation

obligatoire et un cercle pour représenter un type de participation facultatif. La

figure 10.60 montre le diagramme de relation révisé pour les tables EMPLOYÉS

et CLIENTS et montre également comment indiquer chaque type de

participation. Notez que vous placez le symbole représentant le type de

participation à l'extérieur du symbole qui représente le type de relation.

Figure 10.60 Désignation du type de participation pour les tables EMPLOYÉS

et CLIENTS.

Le type de participation s’applique également à une relation d’auto-référence,

bien que d’une manière légèrement différente. En raison de la nature d'une

relation d'auto-référencement, vous désignez le type de participation pour les

champs de clé primaire et de clé étrangère dans la table. La figure

10.61 montre un diagramme de relation révisé pour la table STAFF avec

laquelle vous avez travaillé plus tôt dans ce chapitre.

Figure 10.61 Désignation du type de participation pour les clés primaires et
étrangères de la table STAFF.

Dans ce cas, vous devez avoir au moins un membre du personnel possédant un

numéro d'identification du personnel valide (la clé primaire) qui peut agir en

tant que manager.À l’inverse, vous n’avez pas besoin de fournir un numéro

d’identification de manager (la clé étrangère) pour un tout nouveau membre

du personnel ; cette personne vient peut-être d'être embauchée plus tôt dans

la journée et n'a pas encore été affectée à un département ou à un projet

particulier.
Identifier le degré de participation pour chaque table

Maintenant que vous avez déterminé la manière dont chaque table participera

à la relation, vous devez déterminer le degré de participation de chaque

table. Le degré de participation indique le nombre minimum d'enregistrements

qu'une table donnée doit avoir associés à un seul enregistrement de la table

associée et le nombre maximum d'enregistrements que la table est autorisée

à associer à un seul enregistrement de la table associée. Les facteurs que vous

utilisez pour déterminer le degré de participation (circonstances évidentes, bon

sens ou conformité à un ensemble de normes) sont les mêmes que ceux que

vous avez utilisés pour déterminer le type de participation. Vous identifierez

généralement le degré de participation de certaines tables maintenant et

revisiterez les tables restantes lorsque vous définirez des règles métier pour la

base de données.

Vous utilisez deux nombres séparés par une virgule et placés entre

parenthèses pour représenter le degré de participation pour une table

donnée. Le premier chiffre indique le nombre minimum requis

d'enregistrements associés et le deuxième chiffre indique le nombre maximum

autorisé d'enregistrements associés. Par exemple, un degré de participation tel

que (2,11) indique que la table doit avoir au moins 2 mais pas plus de 11 de

ses enregistrements liés à un seul enregistrement de l'autre table.

Considérez à nouveau les tables EMPLOYÉS et CLIENTS. Il existe une relation

un-à-plusieurs entre ces tables, ce qui signifie qu'un client donné peut être

associé à un seul employé et qu'un employé donné peut être associé à

n'importe quel nombre de clients. (Oui, je sais ; c'est la partie la plus évidente.)

Supposons cependant que votre organisation vient d'instituer une nouvelle

politique fortement axée sur un service client de qualité. Afin de garantir que

chaque représentant de compte puisse fournir le niveau de service requis par

l'organisation, la politique stipule qu'il ne peut pas être affecté à plus de 15

clients à la fois. Sur la base de ce scénario, vous pouvez déduire que le degré

de participation de la table EMPLOYÉS est (1,1) et que le degré de participation

de la table CLIENTS est (0,15).

Après avoir identifié le degré de participation pour une table particulière,

ajoutez les informations au diagramme de relations. Désignez le degré de

participation sur la ligne de connexion du tableau approprié. La figure

10.62 montre le diagramme de relation révisé pour les tables EMPLOYÉS et

CLIENTS.

Figure 10.62 Désignation du degré de participation pour les tables EMPLOYÉS

et CLIENTS.
Le degré de participation s'applique également à une relation d'auto-

référencement, même si vous le désignez pour les champs de clé primaire et

de clé étrangère dans la table, tout comme vous l'avez fait pour le type de
participation.La figure 10.63 montre une version mise à jour du diagramme de

relation pour la table STAFF qui inclut les informations sur le degré de

participation.

Figure 10.63 Désignation du degré de participation pour les clés primaires et

étrangères de la table STAFF.

S TAFF ID a un degré de participation de (0,12) car un manager peut gérer

jusqu'à 12 collaborateurs ; un nouveau manager qui n'a pas encore été affecté

à un département ou à un projet n'aura aucun (ou 0) membre du personnel à

gérer. Le degré de participation pour MANAGER ID est de (1,1) car un membre

du personnel donné est géré par un seul manager.

Vous pouvez désigner un degré de participation illimité pour n'importe quelle

table dans une relation à double table ou champ clé dans une relation d'auto-

référence en utilisant un « N » à la place du deuxième chiffre. Par exemple, la

table ORDERS de la figure 10.64 a un degré de participation illimité. Même si

un nouveau client n’a pas encore passé de commande, vous lui permettrez de

passer autant de commandes qu’il le souhaite. Imaginez l'impact sur l'activité

de votre organisation si vous limitiez chaque client à 35 commandes ! Votre

organisation serait bientôt en faillite si elle ne parvenait pas à acquérir

continuellement et systématiquement de nouveaux clients.

Figure 10.64 Désignation d'un degré de participation illimité pour la table

ORDERS.

Votre tâche consiste maintenant à définir les caractéristiques de chaque

relation que vous avez établie jusqu'à présent. Au fur et à mesure que vous

travaillez sur une relation donnée, veillez à mettre à jour le diagramme de

relation afin qu'il reflète les résultats de votre travail.

Vérification des relations entre les tables avec les utilisateurs et la

direction

La toute dernière chose à faire est de vérifier les relations. Vous pouvez

effectuer cette tâche relativement facilement en utilisant la liste de contrôle

suivante.
1. Assurez-vous d'avoir correctement identifié chaque relation.

2. Assurez-vous que vous avez correctement établi chaque relation.

3. Assurez-vous que chaque clé étrangère est conforme aux éléments d'une

clé étrangère.

4. Assurez-vous d'avoir établi une règle de suppression appropriée pour

chaque relation.

5. Assurez-vous d'avoir identifié le type de participation approprié pour chaque

table au sein d'une relation à deux tables et pour les champs clés appropriés

dans une relation d'auto-référencement.

6. Assurez-vous d'avoir identifié le degré de participation approprié pour

chaque table au sein d'une relation à deux tables et pour les champs clés

appropriés dans une relation d'auto-référencement.

Si toutes les relations sont vérifiées et que toutes les personnes avec lesquelles

vous travaillez acceptent cette évaluation, vous pouvez être sûr que les

relations sont solides et prêtes à être intégrées aux points de vue.

Une note finale

La mesure dans laquelle vous pouvez facilement mettre en œuvre ces trois

caractéristiques de relation dépend grandement de votre SGBDR. La plupart

des SGBDR ne prennent pas entièrement ou intrinsèquement en charge toutes

les caractéristiques, mais ils le font.fournissent un support de base pour la

règle de suppression et le type de participation. Dans la plupart des cas,

cependant, vous pouvez utiliser SQL et du code de programmation pour

implémenter ces caractéristiques pour n'importe quelle relation dans votre

base de données.
Intégrité au niveau des relations

Une relation atteint l'intégrité au niveau relationnel après avoir vérifié qu'elle

est correctement établie et que ses caractéristiques sont correctement

définies. L’intégrité au niveau relationnel garantit ce qui suit.

• La connexion entre les deux tables (ou champs clés) dans une relation est

solide. Pour ce faire, vous avez utilisé des champs de clé primaire et
étrangère pour établir une relation un-à-un ou un-à-plusieurs et une table de

liaison pour établir une relation plusieurs-à-plusieurs.

• Vous pouvez insérer de nouveaux enregistrements dans chaque table de

manière significative. Vous vous en êtes assuré en désignant le type de

participation approprié pour chaque table (ou champ clé) au sein de la

relation.

• Vous pouvez supprimer un enregistrement existant sans produire d'effets

indésirables. Vous l'avez garanti en attribuant une règle de suppression

appropriée à la relation.

• Il existe une limite significative au nombre d'enregistrements pouvant être

interconnectés au sein de la relation. Vous avez mis en œuvre cela en

désignant le degré de participation approprié pour chaque table (ou champ

clé) au sein de la relation.

Comme vous le savez, l’intégrité au niveau relationnel est le troisième élément

de l’intégrité globale des données. (Le premier est l'intégrité au niveau de la

table et le second est l'intégrité au niveau du champ.) Vous établirez le dernier

composant de l'intégrité globale des données dans le chapitre suivant lorsque

vous apprendrez à établir des règles métier pour la base de données.

EXEMPLE : IDENTIFIER ET ÉTABLIR DES RELATIONS

Il est maintenant temps d'identifier les relations qui existent pour les tables qui

apparaissent sur la liste finale des tables de Mike's Bikes. Vous travaillez

actuellement avec ces tables :

CLIENTS

EMPLOYÉS

FACTURES

DES PRODUITS

VENDEURS

Votre première tâche consiste à identifier les relations qui existent

actuellement entre les tables. Vous décidez de rencontrer uniquement Mike car

il y a peu de tables dans cette base de données et vous pensez que Mike

devrait être suffisamment familier avec les tables pour l'aider à vérifier les

relations.

Avant de rencontrer Mike, vous créez une matrice de tableau et identifiez

autant de relations que possible. La figure 10.65 montre votre matrice

complétée.
Figure 10.65 Identification des relations entre les tables de la base de
données Mike's Bikes.

Vous étudiez ensuite attentivement la matrice du tableau et utilisez la formule

appropriée pour déterminer la véritable relation entre chaque paire de

tableaux. Voici ce que vous avez découvert jusqu'à présent.

Les CLIENTS et les FACTURES entretiennent une relation un-à-plusieurs.

(1:1 + 1:N = 1:N)

Les EMPLOYÉS et les FACTURES entretiennent une relation un-à-plusieurs.

(1:1 + 1:N = 1:N)

LES PRODUITS et les FACTURES entretiennent une relation plusieurs-à-

plusieurs.

(1:N + 1:N = M:N)

Maintenant, vous schématisez les relations, les rassemblez dans un dossier,

puis utilisez votre ordinateur portable pour contacter Mike pour votre réunion

en ligne.
Pendant la réunion, vous et Mike travaillez à vérifier les relations. Vous

déterminez tous les deux que les trois relations sont effectivement correctes,

puis vous attirez l'attention de Mike sur les tables PRODUITS et

VENDEURS. Vous n'êtes pas sûr de la relation qui les unit, alors vous en

discutez avec Mike.

TOI :«Je voulais vous poser des questions sur la relation entre les tables

PRODUITS et VENDEURS. Un seul produit peut-il être associé à un ou plusieurs

fournisseurs ? »

MIKE :« Oui, d'une manière de parler. Ce que je veux dire, c'est qu'un seul type

de produit, comme un antivol de vélo, peut être associé à un ou plusieurs

fournisseurs. Mais je donne à chaque serrure son propre numéro de produit et

je la traite comme un article distinct, quel que soit le fournisseur qui la

fournit. Maintenant, si le véritable sens de votre question est de savoir si un

seul enregistrement de la table PRODUCTS peut être associé à un ou plusieurs

enregistrements de la table VENDORS, alors la réponse est « non » car chaque

enregistrement de la table PRODUCTS contient une référence uniquement

à un fournisseur dans la table VENDORS.

TOI :"C'est ce que je pensais. Dans ce cas, il existe une relation un-à-plusieurs

entre les tables VENDORS et PRODUCTS. J'ai automatiquement pensé qu'un

seul fournisseur pouvait être associé à plusieurs produits dans la table

PRODUITS.

Vous allez maintenant schématiser la relation un-à-plusieurs entre les tables

VENDORS et PRODUCTS et passer à l'étape suivante.

Vous établissez chaque relation un-à-plusieurs en prenant une copie de la clé

primaire de la table parent et en l'incorporant dans la structure de la table

enfant (où elle sert de clé étrangère), puis révisez le diagramme de relation en

conséquence. La figure 10.66 montre l'un de vos diagrammes révisés.

Figure 10.66 Le diagramme de relation pour les tables EMPLOYÉS et

FACTURES.

Vous établissez maintenant la relation plusieurs-à-plusieurs entre les tables

INVOICES et PRODUCTS en créant une nouvelle table de liaison appelée

INVOICE PRODUCTS. Vous basez la nouvelle table sur le champ

I NVOICE N UMBER de la table INVOICES et le champ P RODUCT N UMBER de la table

PRODUCTS. La figure 10.67 montre le diagramme de relation révisé pour les

tables FACTURES et PRODUITS.

Figure 10.67 établissant et schématisant la relation plusieurs à plusieurs

entre les tables de factures et de produits.
Vous examinez chaque structure de tableau pour vous assurer qu’elle est

conforme aux éléments du tableau idéal. Heureusement, vous n'avez aucune

modification à apporter car toutes les structures des tables sont solides. Vous

allez maintenant affiner les clés étrangères de chaque table en vous assurant

que chacune est conforme aux éléments d'une clé étrangère. Enfin, vous

modifiez les éléments appropriés dans les sections Éléments généraux et

Éléments logiques de la feuille Spécifications de champ de chaque clé

étrangère. La figure 10.68 montre les modifications que vous avez apportées

pour l'une des clés étrangères. (J'ai mis en évidence les changements afin que

vous puissiez les reconnaître plus facilement.)

Figure 10.68 Les sections des éléments généraux et des éléments logiques
de la feuille de spécifications de champ pour le champ de clé étrangère de l'ID
de la c ustomer dans le tableau des factures.

Votre prochaine tâche consiste à établir les caractéristiques relationnelles

appropriées pour chaque relation. Vous commencez par définir une règle de

suppression pour chaque relation, puis vous identifiez à la fois le type de

participation et le degré de participation pour chaque tableau dans la

relation. Vous accomplissez votre tâche en désignant ces caractéristiques sur le

diagramme de relations. La figure 10.69 montre l'un des diagrammes terminés.

Figure 10.69 Le diagramme de relation complété pour les tables EMPLOYÉS et

FACTURES.

Mike et vous examinez et vérifiez toutes les relations une dernière fois. Vous

êtes tous les deux d’accord sur le fait que tout est terminé, alors maintenant

vous en avez terminé avec cette partie du processus.

Résumé

Nous avons ouvert ce chapitre avec une discussion des trois types de relations

qui peuvent exister entre une paire de tables particulière: un à un, un à

plusieurs et plusieurs à plusieurs. Vous savez maintenant que la relation un-à-

plusieurs est le type de relation à table double le plus courant et que la relation

plusieurs-à-plusieurs donne lieu à des problèmes qui doivent être résolus. Vous

avez ensuite appris une relation d'auto-référence , qui est un type de relation

qui se produit entre les enregistrements dans un tableau donné. Elle est

similaire à une relation à double table dans la mesure où elle peut être un-à-un,

un-à-plusieurs ou plusieurs-à-plusieurs.

Ensuite, nous avons discuté de la façon d' identifier les relations qui existent

entre les tableaux d'une base de données. Vous avez d’abord appris à

construire et à utiliser une matrice de tableau, puis à utiliser des

questions associatives et contextuelles pour vous aider à identifier une relation

donnée. Nous avons ensuite discuté de trois formules que vous pouvez utiliser

pour déterminer la véritable relation qui existe entre les tables dans une

relation à deux tables ou entre les enregistrements dans une relation d'auto-

référencement.
Le chapitre se poursuit avec une discussion sur la manière dont les relations

sont établies. Vous avez appris que un à un et un à plusieursles relations sont

établies à l'aide de clés primaires et de clés étrangères, et les relations

plusieurs-à-plusieurs sont établies à l'aide de tables de liaison. Nous avons

ensuite brièvement revisité des champs multivus, et vous avez appris à utiliser

une relation un-à-plusieurs appropriée pour résoudre un champ multivaleur

plus efficacement. Ensuite, nous avons discuté des relations d'auto-

référencement, et vous savez maintenant que vous les établissez d'une

manière très similaire aux relations à double table. Vous avez alors appris que

vous devez revoir toutes les structures de table et vous assurer qu'elles sont

toujours conformes aux éléments de la table idéale.

Les clés étrangères ont été le prochain sujet de discussion et vous avez appris

que chaque clé étrangère doit être conforme aux éléments d'une clé

étrangère. Vous savez maintenant qu'il peut être très important qu'une clé

étrangère partage le même nom que sa clé primaire parent, que vous devez

modifier certains éléments d'une spécification de champ pour un champ qui

sert de clé étrangère, et qu'une clé étrangère doit tirer ses valeurs de la clé

primaire parent.
Nous avons ensuite discuté des caractéristiques relationnelles. Vous avez

appris comment définir une règle de suppression pour une relation et que vous

pouvez la définir de quatre manières. Ensuite, vous avez appris à identifier

le type de participation et le degré de participation pour chaque table dans une

relation à double table et pour chaque champ clé dans une relation d'auto-

référence. Comme vous le savez maintenant, vous pouvez désigner le type de

participation comme obligatoire ou facultatif. Vous savez également que le

degré de participation évalue le nombre minimum et maximum

d'enregistrements interdépendants qui peuvent exister dans une relation

donnée. Enfin, vous avez appris que vous devez vérifier les relations avec les

utilisateurs et la direction et que vous pouvez utiliser une liste de contrôle pour

accomplir cette tâche.

Le chapitre a clôturé avec un aperçu de l'intégrité au niveau de la

relation. Vous avez appris qu'une relation atteint ce type d'intégrité après avoir
vérifié qu'elle est correctement établie et que ses caractéristiques sont

convenablement définies.

Questions de révision

1. Énoncez deux principales raisons pour lesquelles une relation est

importante.

2. Nommez les trois types de relations.

3. Quelle relation posera le plus de problèmes?

4. Énoncez deux problèmes que vous pourriez éventuellement rencontrer avec

une relation plusieurs-à-plusieurs.

5. Qu'est-ce qu'une relation d'auto-référence ?

6. Comment commencer le processus d' identification des relations entre les

tables de la base de données ?

7. Quels sont les deux types de questions que vous pouvez poser pour vous

aider à identifier les relations existantes ?

8. Quel symbole raccourci utilisez-vous pour désigner une relation un-à-

plusieurs dans la matrice de la table?

9. Comment déterminez-vous quel type de relation existe officiellement entre

chaque paire de tableaux de la matrice ?

10. Comment établir une relation un-à-plusieurs ?

11. Vrai ou faux : Récupérer des informations à partir de tables avec une

relation d'auto-référencement peut être fastidieux et quelque peu difficile.

12. Comment établissez-vous une relation de plusieurs à plusieurs références?

13. Comment affiner les clés étrangères dans la base de données ?

14. Quelles deux catégories d'éléments devez-vous modifier pour la

spécification de champ d'une clé étrangère ?

t
a
b Quelle est la fonction d’une règle de suppression ?
15.
l
e
16. Quels deux types de participation pouvez-vous désigner pour une table ?

d
e17. Qu'indique le degré de participation ?
s
P
ar
rem Quand une relation atteint -elle l’intégrité au niveau relationnel ?
18.
ac
ht
m
dq
èei
ou
trè
se
rc
u
eh
e
se
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
10. Relations entre les tables
11. Règles commerciales
12. Vues
3h 32min restant

11

Règles commerciales

On se souvient de vous pour les règles que vous enfreignez.

—G d ouglas m ac a rthur _

Sujets abordés dans ce chapitre

Que sont les règles commerciales?

Catégories de règles métier

Définir et établir des règles métier

Tableaux de validation

Examiner les feuilles de spécifications des règles commerciales

Exemple : définir et établir des règles métier

Résumé

Questions de révision

Tout au long du processus de conception de la base de données, vous avez

effectué des tâches qui ont contribué à établir différents niveaux d'intégrité des

données. Vous avez établi l'intégrité au niveau du tableau, l'intégrité au niveau

du champ et l'intégrité au niveau de la relation jusqu'à présent. Ce faisant,

vous avez veillé à ce que les structures de table et de champs soient solides,

que les données entrées dans les champs seront cohérentes et essentiellement

valides, et que les relations sont significatives et correctement établies. Dans

ce chapitre, vous apprendrez à établir le composant final de l'intégrité globale

des données: les règles métier .

Que sont les règles commerciales?

Une règle commerciale est une déclaration qui impose une forme de contrainte

sur un aspect spécifique de la base de données, tels que les éléments dans une

spécification de champ pour un champ particulier ou les caractéristiques d'une

relation donnée. Vous basez une règle métier sur la manière dont l'organisation

perçoit et utilise ses données, que vous déterminez à partir de la manière dont

l'organisation fonctionne ou mène ses activités.

Un aspect important de tout processus de conception consiste à faire des

choix. Dans la conception de la base de données, par exemple, vous devez

choisir les données à stocker dans la base de données; Vous ne voudriez pas

nécessairement stocker ou avoir besoin de stocker toutes les dernières

données que l'organisation pourrait éventuellement utiliser. Les données que

vous choisissez enfin de stocker et comment vous décidez de les stocker seront

déterminées par la façon dont l'organisation utilise ses données. Un hôpital

peut vouloir stocker des temps de divers événements à la seconde, tandis

qu'un entrepôt ne nécessite que la date pour un événement donné.

Pour guider ces choix et d'autres, vous devrez faire pendant le processus de

conception de la base de données (et plus tard, lorsque vous implémentez la

base de données dans un SGBDR), vous avez besoin d'une déclaration formelle

des règles commerciales de l'organisation. Ces règles influenceront une grande

variété de problèmes de base de données, tels que les données que vous

collectez et stockez, la manière dont vous définissez et établissez des relations,

les types d'informations que la base de données peut fournir et la sécurité et la

confidentialité même des données elle-même . La création d'un ensemble

générique de règles commerciales qui pourrait s'appliquer à deux organisations

ou plus est presque impossible. Chaque organisation possède ses propres

exigences de données et d'informations, et chacune a sa propre façon unique

de mener ses activités; par conséquent, chaque organisation a besoin de son

propre ensemble spécifique de règles métier.

La déclaration suivante est un exemple de règle commerciale typique:

Comme la hanche ne peut pas être avant un o rder pour une commande donnée.
Cette règle métier particulière impose une contrainte sur l’élément Range of

Values des spécifications de champ pour un champ S HIP D ATE . Cela permettra

de garantir que la valeur de S HIP D ATE est significative dans le contexte d'une

commande client. Sans cette contrainte, vous pourriez saisir n'importe quelle

date dans le champ (y compris une date antérieure à la DATE DE

COMMANDE ) , rendant la valeur du champ DATE D' EXPÉDITION absolument dénuée

de sens. La règle d'entreprise est ce qui rend la valeur du champ de la hanche .

Parce que les règles métier dépendent de la manière dont une organisation

perçoit et utilise ses données, il est fort possible que plusieurs organisations

utilisent une règle particulière, mais pour des raisons

complètement différentes .

Par exemple, dites que le département de musique de Bel Air High School est

connu de loin pour la qualité de la musicalité qu'elle développe chez ses

étudiants musiciens. Les étudiants sont capables d'atteindre ce niveau de

musicalité parce qu'ils sont encouragés à concentrer leurs études musicales et

à se limiter à apprendre à jouer de deux instruments au maximum. Dans une

autre partie de la ville, le département de musique de Lake City High School

(une école privée) confère également à ses étudiants musiciens une grande

qualité musicale en les aidant à concentrer leurs études musicales. Les élèves

de cette école sont également limités à l'apprentissage de ne pas jouer plus de

deux instruments en raison de la politique de l'école; L'inventaire des

instruments de musique de l'école est très limité.

Par coïncidence, les deux écoles sont en train de concevoir leur propre base de

données. Dans chaque cas, l'école utilisera la base de données pour soutenir

ses opérations quotidiennes et ses fonctions administratives. Il se trouve que

chaque base de données contient les tables présentées dans la figure 11.1 .
Figure 11.1 Tableaux des bases de données des lycées Bel Air et Lake City.

Les deux écoles sont au même stade du processus de conception de bases de

données et établissent actuellement des règles métier. Il s'avère que chaque

école utilise la règle commerciale suivante dans sa base de données

respective:

Un élève ne peut pas faire vérifier plus de deux instruments en même temps.

Cette règle d'entreprise s'applique au degré de participation entre le tableau

des étudiants et le tableau des instruments des étudiants. Dans ce cas, un seul

enregistrement dans le tableau des étudiants ne peut pas être associé à plus

de deux enregistrements dans le tableau des instruments des étudiants où la

valeur de C Heck -i n d ate pour chaque enregistrement est nul; Un caractère nul

dans le champ C HECK -I N D ATE indique que l'instrument est toujours en

possession de l'étudiant.
La règle s'applique aux deux écoles, mais chaque école l'exige pour une raison

différente. Bel Air High School exige la règle en raison de la manière dont son

programme de musique a été établi, tandis que le Lake City High School

nécessite la contrainte en raison des limites physiques de son inventaire

d'instruments. Le fait que les deux écoles aient développé une règle identique

est une pure coïncidence. Cet exemple illustre qu'une règle d'entreprise est en

effet basée sur la façon dont unl’organisation fonctionne ou mène ses activités

et démontre pourquoi chaque organisation doit avoir son propre ensemble

spécifique de règles commerciales.

L'exemple illustre également un autre problème : vous ne pouvez pas établir de

contraintes imposées par certaines règles métier, comme celle-ci, dans la

conception logique de la base de données. Par exemple, il n'existe aucun

moyen clair pour indiquer que les valeurs C HECK -I N D ATE doivent être testées

pour déterminer si un étudiant peut vérifier un autre instrument. Vous devez

plutôt aborder et établir la contrainte en dehors de la conception logique de la

base de données. Comment déterminez-vous si vous pouvez représenter

correctement une contrainte donnée dans ce processus? Vous le faites en

identifiant le type de règle commerciale que vous définissez.

Types de règles métier

Les deux principaux types de règles métier sont orientés vers la base de

données et orientés vers l'application. Les deux types de règles commerciales

imposent une certaine forme de contrainte et aident à appliquer et à maintenir

l'intégrité globale des données, mais elles diffèrent en ce qui concerne l'endroit

et comment elles sont établies.

Les règles métier orientées base de données imposent des contraintes que
vous pouvez établir dans le cadre de la conception logique de la base de

données. Vous implémentez une contrainte donnée en modifiant divers

éléments de spécification de champ, caractéristiques relationnelles ou une

combinaison des deux. La déclaration à partir de laquelle vous dérivez la

contrainte est une règle commerciale orientée vers la base de données si vous

pouvez établir de manière significative et clairement la contrainte par l'un ou

l'autre de ces moyens. Par exemple, disons que vous avez une table de

fournisseurs et définissez la règle commerciale suivante pour le champ

de fin de fin dans ce tableau:

Nous faisons affaire exclusivement avec des fournisseurs du nord-ouest du

Pacifique.

Cette règle métier limite les valeurs que vous pouvez saisir dans le champ

V END S TATE à WA, OR, ID et MT. Vous pouvez créer l'entrepriseLa contrainte de

la règle de manière significative en modifiant l'élément de plage de valeurs

dans les spécifications de champ pour le champ de fin de fin . La figure

11.2 montre la modification.

Figure 11.2 Implémentation d'une contrainte imposée par une règle
d'entreprise orientée vers la base de données.

Les règles métier orientées applications imposent des contraintes que vous ne

pouvez pas établir dans le cadre de la conception logique de la base de

données. Vous devez plutôt les établir dans la conception physique de la base

de données ou dans la conception d'une application de base de données , où

ils seront plus applicables et plus significatifs. (J'utilise le terme application de

base de données ici pour désigner un programme écrit dans certains logiciels
qui permet aux personnes de l'organisation d'utiliser facilement la base de

données et d'effectuer des tâches liées à leurs activités de travail

quotidiennes.)

Voici un exemple d'une règle commerciale axée sur les applications typique:

Un client avec un statut « Préféré » bénéficie d'une réduction de 15 % sur tous

les achats.

Cette règle d'entreprise détermine le montant de la remise appliquée aux

achats d'un client, en fonction d'un statut particulier. Vous ne pouvez pas

établir cette contrainte de manière significative dans la conception logique

pour deux raisons: il n'y a pas de champ dans lequel stocker le montant de

réduction (le montant est le résultat d'un calcul, et les champs calculés ne sont

pas autorisés dans un tableau), et il n'y a pas moyen d'indiquer le critère utilisé

- lele statut du client – pour déterminer la remise. Vous devez établir cette

règle dans la conception physique de la base de données ou dans la conception

de l' application de base de données.

Note
La manière dont vous définissez et établissez réellement les règles

commerciales axées sur les applications est un sujet qui dépasse le cadre de ce

livre. Certains RDBDS fournissent des outils qui vous permettent d'implémenter

relativement facilement les règles commerciales axées sur les applications; La

plupart des RDBS vous obligeront à écrire du code de programmation pour

implémenter et appliquer ces règles.

Bien que les deux types de règles métier soient importants, vous vous

concentrerez sur les règles métier orientées base de données au cours de cette

étape du processus de conception de base de données.

Note

Tout au long du reste du livre, je me référerai aux règles commerciales axées

sur la base de données simplement en tant que règles métier .

Catégories de règles métier

Comprendre et définir les règles métier est plus facile si vous les divisez en

deux catégories distinctes : spécifiques au domaine et spécifiques à la relation.

Règles métier spécifiques au champ

Les règles commerciales dans la catégorie spécifique au champ imposent des

contraintes aux éléments d'une spécification de champ pour un champ

particulier. Le nombre d'éléments affectés par une règle donnée dépend de la

manière dont vous définissez cette règle. Par exemple, cette règle n'affecte

qu'un seul élément:

Les dates de commande ne peuvent pas être antérieures au 16 mai 2018, date

de création de notre entreprise.

Cette règle affecte la plage de dates qui peuvent être saisies dans le champ

O RDER D ATE d'une table ORDERS. Vous établissez cette règle en modifiant

l'élément Plage de valeurs des spécifications du champ DATE DE COMMANDE pour

indiquer la plage de dates valides.

Voici une règle qui affecte plusieurs éléments :

Nous devons être en mesure de stocker un code postal pour nos clients

canadiens.

Cette règle affecte les éléments Type de données, Longueur et Prise en charge

des caractères des spécifications de champ pour le champ C UST Z IPCODE dans

une table CUSTOMERS. Les codes postaux étendus contiennent des tirets et les

codes postaux canadiens incluent des lettres, vous devez donc apporter les

modifications suivantes à ces éléments pour imposer les contraintes définies

par cette règle.

1. Modifiez le paramètre Type de données sur « Alphanumérique ».

2. Définissez le réglage de longueur sur «9». (Cela vous permet d'inclure des

codes postaux étendus.)

3. Incluez « Lettres » et « Clavier » sous l'élément Support de personnage.

La figure 11.3 montre la section modifiée des éléments physiques des

spécifications de champ de C UST Z IPCODE .

Figure 11.3 Établissement d'une règle commerciale spécifique au champ pour
C ust z ipcode .

Règles métier spécifiques à la relation

Les règles métier spécifiques à une relation imposent des contraintes qui

affectent les caractéristiques d'une relation. Par exemple, supposons que vous

travaillez avec les tables et les relations de la figure 11.4 .

Figure 11.4 Tableaux et relations provenant d'une base de données scolaire.

Supposons que vous déterminiez qu'il doit y avoir une limite au nombre

d'étudiants pour chaque classe et que vous définissiez la règle métier

suivante :

Chaque classe doit compter au minimum cinq élèves, mais ne peut en accueillir

plus de 20.
Cette règle métier affecte le degré de participation entre les tables CLASSES et

STUDENT CLASSES. Vous appliquez la contrainte définie par cette règle en

modifiant le diagramme de relations pour montrer qu'un seul enregistrement

de la table CLASSES doit être lié à au moins cinq (mais pas plus de 20)

enregistrements dans la table STUDENT CLASSES. (Selon votre point de vue,

vous pourriez également déduire de cette règle métier que le type de

participation pour la table COURS D'ÉTUDIANTS est désormais obligatoire. Vous

pouvez saisir une nouvelle classe ou conserver une classe existante dans la

table CLASSES si et seulement si à au moins cinq étudiants sont inscrits dans

ce cours.) La figure 11.5 montre la modification que vous devez apporter au

diagramme pour établir la règle métier.

Figure 11.5 Établissement d'une règle métier spécifique à la relation.

Définir et établir des règles métier

Vous définissez et établirez des règles métier pour la base de données au cours

de cette étape du processus de conception. N'oubliez pas que vous devez

fonder ces règles sur la manière dont votre organisation perçoit et utilise ses

données, qui (comme vous le savez) dépendra de la façon dont l'organisation

fonctionne ou mène ses activités. La meilleure approche de cette tâche

consiste à définir et à établir d'abord les règles commerciales spécifiques au

domaine, suivies des règles commerciales spécifiques à la relation. Cette

approche vous aide à rester concentré sur le type de règle que vous

définissez. Cela vous empêche également de sauter dans les différents types

de règles commerciales, ce qui peut souvent conduire à la confusion et une

certaine frustration.

Travailler avec les utilisateurs et la gestion

Encore une fois, vous travaillerez avec le groupe représentatif des utilisateurs

et de la direction. Planifiez de nouvelles réunions avec eux afin que vous

puissiez travailler ensemble pour définir et établir les règles commerciales

appropriées pourla base de données. Travailler en groupe vous permet de vous

assurer que les contraintes imposées par les règles métier que vous définissez

ont du sens et qu'il n'y a pas de confusion ou d'ambiguïté quant à la nécessité

d'imposer chaque contrainte. Si vous ou quelqu'un dans le groupe avez un

doute sur une contrainte, vous pouvez discuter de l'effet qu'elle aura sur le

terrain ou la relation impliquée et les avantages et les inconvénients d'imposer

la contrainte. Vous pouvez alors décider de conserver la règle ou de l’ignorer

complètement en fonction des résultats de votre discussion.

Définir et établir des règles métier spécifiques au domaine

Commencez le processus d'établissement de règles métier pour la base de

données en travaillant sur des règles spécifiques au champ. Vous définissez et

établissez chaque règle en utilisant ces étapes.

1. Sélectionnez un tableau.

2. Passez en revue chaque champ et déterminez si cela nécessite des

contraintes.

3. Définir les règles métier nécessaires pour le terrain.

4. Établissez les règles en modifiant les éléments de spécification de champ

appropriés.

5. Déterminez quelles actions testent la règle.

6. Enregistrez la règle sur une feuille de spécifications des règles métier. (Nous

avons travaillé avec des morceaux de la feuille jusqu'à présent, mais

regardez la figure 11.8 pour voir une feuille complète.)

Examinons maintenant chaque étape plus en détail.

Étape 1 : Sélectionnez une table

Peu importe la table que vous sélectionnez en premier, car vous appliquerez

éventuellement cette procédure à chaque table de la base de données. Si vous

choisissez une table avec une structure familière, vous pouvez vous concentrer

un peu plussur l'apprentissage des étapes de la procédure. Cet effort

supplémentaire versera des dividendes lorsque vous commencerez à travailler

avec des tables contenant des champs qui portent une attention et un examen

plus approfondis.

Pensez au sujet que représente le tableau, puis posez ces questions:

Comment l'organisation utilise-t-elle des informations en fonction ou liées à ce

sujet?
Quelles relations cette table entretient-elle avec elle-même ou avec d'autres

tables de la base de données ?

Si nécessaire, consultez la liste finale des tableaux, lisez la description de ce

tableau et référez-vous à tous les diagrammes de relations qui intègrent ce

tableau. Les réponses à ces questions vous seront utiles pendant que vous

définissez des règles pour ce tableau et que vous vous concentrez sur le

tableau de cette manière vous prépare à la prochaine étape.

Étape 2 : Examinez chaque champ et déterminez s'il nécessite des contraintes

Examinez la feuille Spécifications du champ pour chaque champ et déterminez

si vous devez appliquer une contrainte à l'un de ses éléments. Gardez les

questions de l’étape 1 à l’esprit lorsque vous examinez une fiche technique

donnée, puis posez cette question :

Sur la base de la façon dont la table est utilisée dans la base de données, une

contrainte est-elle nécessaire pour tout élément de cette spécification?

Si la réponse est «non», passez au champ suivant; Sinon, passez à l'étape

suivante. Par exemple, supposons que vous travaillez avec le champ

C UST C OUNTY dans une table CUSTOMERS et que vous venez de poser la

question sur la nécessité d'une contrainte. ( La figure 11.6 montre la catégorie

des éléments logiques actuels pour ce champ.)

Figure 11.6 Paramètres actuels de la catégorie Éléments logiques du champ
C UST C OUNTY .

Vous devriez passer à l'étape suivante si vous recevez une réponse telle que

celle-ci :

« Eh bien, le patron veut commencer à suivre nos clients par comté, nous

devons donc nous assurer d'enregistrer un comté pour chaque client. En fait,

nous venons d'ajouter les comtés de Pierce et de Snohomish à notre région de

vente, il sera donc impératif que les noms des comtés soient enregistrés.

Cette réponse est clairement « oui », vous allez donc définir les règles métier

pour ce domaine à l'étape suivante.

Étape 3 : Définir les règles métier nécessaires pour le terrain

Vous définissez les règles métier appropriées pour le champ C UST C OUNTY en

identifiant les contraintes impliquées par la réponse à l'étape 2. Vous

transformez ensuite chaque contrainte en règle.

La réponse à l'étape 2 suggère deux contraintes possibles que vous devriez

imposer au champ C UST C OUNTY : Un nom de comté est requis pour chaque

client et la plage de valeurs pour ce champ est limitée à quatre comtés

spécifiques (les deux actuellement sur le spécification du champ et les deux

nouveaux comtés indiqués dans la réponse). Voici deux instructions que vous

pouvez utiliser pour commencer à transformer ces contraintes en règles

métier :

Un comté doit être associé à chaque client.

Les seuls comtés pouvant être saisis dans ce champ sont King, Kitsap, Pierce et

Snohomish.

Après avoir défini les règles métier appropriées, vous pouvez passer à l'étape

4.

Étape 4 : Établir les règles en modifiant les éléments de spécification de champ

appropriés

Établissez chaque règle métier que vous avez définie à l'étape 3 en modifiant

les éléments appropriés sur la feuille Spécifications du champ. (N'oubliez pas

que certaines règles peuvent affecter plusieurs éléments.) Toutefois, vous

devez d'abord identifier les éléments des spécifications de champ affectés par

la règle. Par exemple, considérez la première règle commerciale que vous avez

définie pour le champ CustCounty à l'étape 3:

Un comté doit être associé à chaque client.

Vous pouvez en déduire que la règle affecte les éléments Valeur requise, Prise

en charge nulle et Modifier la règle, car elle indique explicitement qu'un comté

« doit être associé » à un client. Vous pouvez maintenant apporter les

modifications appropriées à ces éléments. Dans ce cas particulier, vous

définirez la valeur requise sur « Oui », la prise en charge des valeurs nulles sur

« Aucune valeur nulle » et la règle de modification sur « Entrer maintenant,

modifications autorisées ».

Comme vous pouvez le constater, il est important que vous examiniez très

attentivement chaque règle métier afin de déterminer les éléments de

spécification de champ qu'elle affectera. Lorsque vous commencez à définir

des règles métier, il est préférable d'avoir une feuille de spécifications de

champ à portée de main afin de pouvoir vous y référer si nécessaire. De

nombreux éléments vous viendront plus facilement à l’esprit à mesure que

vous deviendrez plus expérimenté dans l’établissement de règles

commerciales.

Considérons maintenant la règle métier suivante dans l'exemple :

Les seuls comtés pouvant être saisis dans ce champ sont King, Kitsap, Pierce et

Snohomish.

Cette règle métier affecte l'élément Plage de valeurs et vous allez maintenant

modifier son paramètre sur « King, Kitsap, Pierce et Snohomish ». La figure

11.7 montre la catégorie des éléments logiques révisés de la feuille de

spécifications de champ pour le champ C ust C OUNTY .

Figure 11.7 Paramètres révisés pour la catégorie Éléments logiques du champ
C UST C OUNTY .

Étape 5 : Déterminer quelles actions testent la règle

La contrainte imposée par la règle métier est testée lorsque vous tentez

d'effectuer l'une des trois actions suivantes : insérer un enregistrement dans la

table ou une entrée dans un champ, supprimer un enregistrement de la table

ou une valeur dans un champ, ou mettre à jour la valeur d'un

champ. Maintenant que vous avez établi une règle métier et compris la

contrainte qu'elle imposera, déterminez les actions qui testent la règle en

identifiant le moment où une violation de la règle est la plus susceptible de se

produire. Vous pouvez rendre cette tâche relativement facile en vous posant les

questions suivantes :

Cette règle sera-t-elle violée si j'entre un nouvel enregistrement dans cette

table ?

Cette règle sera-t-elle violée si je n'entre pas de nouvel enregistrement dans

cette table ?
Cette règle sera-t-elle violée si je supprime un enregistrement de cette table ?

Cette règle sera-t-elle violée si j'entre une valeur dans ce champ ?

Cette règle sera-t-elle violée si je ne saisis pas de valeur dans ce champ ?

Cette règle sera-t-elle violée si je mets à jour la valeur de ce champ ?

Cette règle sera-t-elle violée si je supprime la valeur de ce champ ?

Après avoir déterminé quelles actions déclencheront une violation de la règle,

notez-les ; vous les utiliserez à l'étape suivante. Ces informations vous aideront

également à établir cette règle de la manière la plus efficace possible lorsque

vous implémentez la base de données dans vos SGBDR.

Dans ce cas, la règle commerciale du champ C ust C OUNTY sera testée lorsque

vous essayez d' insérer une valeur dans le champ car la valeur doit être dans

une plage spécifique de valeurs. La règle sera également testée lorsque vous

tenterez de supprimer une valeur dans le champ car la valeur ne peut pas être

Null.

Étape 6: Enregistrez la règle sur une feuille de spécifications de règles commerciales

Vous pouvez documenter une règle commerciale donnée pour référence future

en remplissant une feuille de spécifications de règles commerciales. C'est

quelque chose que vous devez faire pour chaque règle, quel que soit son type

ou sa catégorie. La feuille de spécifications des règles métier offre trois

avantages.

1. Il vous permet de documenter chaque règle commerciale axée sur la base

de données. Cela vous aide à vous assurer que vous avez correctement
défini et correctement établi chaque règle.
2. Il vous permet de documenter chaque règle commerciale axée sur les

applications. Bien que vous ne puissiez pas établir ce type de règle dans la
conception logique de la base de données, vous pouvez au moins indiquer

ses éléments de base. Les informations que vous documentez pour ce type

de règle commerciale vous seront inestimables lorsque vous implémentez la

base de données dans votre SGBDR ou lorsque vous créez le programme

d'application que les gens utiliseront pour travailler avec la base de

données.

3. Il fournit une méthode standard pour enregistrer toutes les règles

métier. Les règles commerciales sont plus faciles à suivre et à entretenir si

vous les enregistrez de manière cohérente. L'utilisation d'un format

uniforme facilite également le dépannage des règles métier ; Chaque aspect

de la règle apparaît sur la fiche de spécification.

La feuille Spécifications des règles métier contient les éléments suivants.

• Déclaration: Ceci est le texte de la règle commerciale elle-même. Il doit être

clair et succinct et doit transmettre les contraintes requises sans aucune

confusion ni ambiguïté. Voici un exemple de déclaration bien cadrée:

Un agent de réservation ne peut être affecté à plus de 25 artistes.

• Contrainte : ceci est une brève explication de la façon dont la contrainte

s'applique aux tables et aux champs. Par exemple, vous pouvez utiliser

l'explication suivante de la contrainte imposée par la règle d'entreprise dans

l'exemple précédent:

Un seul enregistrement de la table AGENTS ne peut pas être associé à plus

de 25 enregistrements de la table ENTERTAINERS.

• Type : C'est ici que vous indiquez si la règle est orientée base de données ou

orientée application.

• Catégorie: c'est là que vous indiquez si la règle est spécifique au champ ou

spécifique à la relation.
• Test on: Voici où vous indiquez quelles actions (insérer, supprimer, mettre à

jour) testera la contrainte que la règle commerciale impose.

• Structures affectées: Selon le type de règle commerciale, la contrainte

affectera soit un champ ou une relation. C'est ici que vous désignez le nom

du ou des champs que la règle affectera ou le nom de la ou des tables

impliquées dans la relation affectée par la règle.

• Éléments de champ affectés : une règle métier relative à un champ peut

affecter un ou plusieurs éléments des spécifications de ce champ. C'est là

que vous indiquez les éléments que la règle affecte.

• Caractéristiques relationnelles affectées: Une règle d'entreprise qui

concerne une relation affectera une ou plusieurs des caractéristiques de la

relation. C'est là que vous indiquez les caractéristiques que la règle affecte.

• Action prise: Ici, vous indiquez les modifications que vous avez apportées

aux éléments d'une spécification de champ ou à un diagramme

relationnel. Commencez votre entrée avec la date à laquelle la modification

a été effectuée et le nom ou les initiales de la personne qui a autorisé ou

effectué le changement. Il est très important que la déclaration que vous

entrez ici soit aussi claire et sans ambiguïté que possible. Si un problème

survient suite à l'application de cette règle métier, cette déclaration

constitue une documentation précise des étapes que vous avez suivies pour

établir la règle. Vous pouvez utiliser cette déclaration pour vous assurer que

ces étapes ont été réellement effectuées et que la règle a été correctement

établie.

Maintenant, remplissez une feuille de spécifications des règles métier pour la

règle que vous avez établie à l'étape 4. La figure 11.8 montre une feuille de

spécifications des règles métier complétée qui documente les règles métier

que vous avez établies pour le champ C UST C OUNTY .

Figure 11.8 Un exemple de feuille de spécifications de règles commerciales.

Définir et établir des règles commerciales spécifiques aux relations

Après avoir défini et établi des règles commerciales spécifiques au terrain , le

prochain ordre des affaires est de lutter contre les règles

commerciales spécifiques aux relations . La procédure pour effectuer cette

tâche implique les étapes suivantes:

1. Sélectionnez une relation.

2. Passez en revue la relation et déterminez si elle nécessite des contraintes.

3. Définissez les règles commerciales nécessaires pour la relation.

4. Établissez la règle en modifiant les caractéristiques de la relation

appropriées.

5. Déterminez quelles actions testeront la règle.

6. Enregistrez la règle sur une feuille de spécifications des règles métier.

Comme vous pouvez le voir, cette procédure est similaire à celle que vous avez

utilisée pour les règles métier spécifiques au terrain. Examinons maintenant

chaque étape plus en détail.

Note

Vous pouvez appliquer l’intégralité de cette procédure aux relations d’auto-

référencement et aux relations à double table. Cependant, j'ai basé le reste de

la discussion sur une relation à double table, car c'est le type de relation que

vous êtes susceptible de travailler avec la majorité du temps.

Étape 1 : Sélectionnez une relation

La relation que vous choisissez est une question relativement triviale, car vous

finirez par appliquer cette procédure à chaque relation de toute façon. Après

avoir sélectionné une relation spécifique, passez en revue son schéma de

relation. Pensez à ce que les tableaux représentent et pourquoi ils sont liés et

posent les questions suivantes:

Quel type d’informations ces tableaux fournissent-ils ?

Pourquoi la relation entre ces deux tables est-elle importante?

La réponse à ces questions vous aidera à définir toutes les règles commerciales

nécessaires pour la relation, et les garder à l'esprit vous préparera à la

prochaine étape.

Étape 2 : Examiner la relation et déterminer si elle nécessite des contraintes

Passez en revue brièvement chaque caractéristique relationnelle et gardez à

l'esprit son cadre actuel. Examinez la relation dans son ensemble et

déterminez si elle nécessite une certaine forme de contrainte. Pendant que

vous examinez la relation, souvenez-vous des réponses aux questions que vous

avez posées à l'étape 1.Vous posez maintenant une question comme celle-ci

pour vous aider à déterminer si une contrainte est nécessaire :

Y a-t-il besoin d'imposer un certain type de limitation à cette relation en

fonction de la façon dont l'organisation fonctionne ou mène ses activités?

Si la réponse est « oui », passez à l’étape suivante ; sinon, passez en revue la

relation suivante et effectuez à nouveau cette étape. Par exemple, supposons

que vous concevez une base de données pour un petit studio de danse et que

vous travaillez avec la relation entre les tables INSTRUCTORS et INSTRUCTOR

CLASSES illustrées dans la figure 11.9 .

Figure 11.9 Un diagramme de relations pour les tables d'une base de

données de studio de danse.

Posez maintenant une question pour vous aider à déterminer si la relation

nécessite une contrainte :

Est-il nécessaire d’imposer une certaine forme de limitation à cette relation en

fonction de la manière dont le studio de danse fonctionne ou mène ses

activités ?

Passez à l'étape suivante si vous recevez une réponse telle que celle-ci :
Oui il y a. Nous exigeons que tous les instructeurs donnent au moins un

cours. Nous les limitons cependant à enseigner dans un maximum de huit

classes.

Vous utiliserez cette réponse comme base d’une règle métier à l’étape

suivante.

Étape 3: Définissez les règles commerciales nécessaires pour la relation

Ensuite, définissez une règle commerciale appropriée en fonction de la réponse

que vous avez reçue à l'étape 2. Identifiez la contrainte que la réponse

implique, puis transformez-la en règle commerciale. Par exemple, vous pouvez

déduire deux contraintes de la réponse: le nombre minimum de classes qu'un

instructeur peut enseigner en est un, et le nombre maximum est de

huit. Transformez ces contraintes en règle métier en composant une instruction

telle que celle-ci :

Un instructeur doit enseigner une classe, mais pas plus de huit classes.

Après avoir défini la règle, passez à l'étape suivante.

Étape 4: Établissez la règle en modifiant les caractéristiques de la relation

appropriées

Établissez la règle métier que vous venez de définir en modifiant les

caractéristiques appropriées dans le diagramme de relations. Avant d'apporter

des modifications, examinez à nouveau l'énoncé de la règle métier et identifiez

les caractéristiques de relation affectées par la règle :

Un instructeur doit enseigner une classe, mais pas plus de huit classes.
La contrainte affecte le nombre de cours qu'un instructeur peut enseigner,

vous modifiez donc la caractéristique de degré de participation de la table

INSTRUCTOR CLASSES en la définissant sur « (1,8) ». Cette règle affecte

également le type de participation caractéristique du tableau COURS

D'INSTRUCTEUR. Vous devez définir le type de participation de la table à «

Obligatoire » car un seul enregistrement de la table INSTRUCTEURS doit être

associé à au moins un enregistrement de la table INSTRUCTEURS CLASSES. La

figure 11.10 montre le diagramme de relation révisé avec vos modifications.

Figure 11.10 Le diagramme de relations révisé qui établit la nouvelle règle

commerciale.
Étape 5 : Déterminer quelles actions testeront la règle

Comme vous le savez, la contrainte imposée par la règle métier est testée

lorsque vous tentez d'insérer, de supprimer ou de mettre à jour un

enregistrement de table ou une valeur de champ. Maintenant que vous avez

établi la règle métier et compris comment elle affecte la relation, déterminez

les actions qui testent la règle en identifiant le moment où une violation de la

règle est la plus susceptible de se produire. Utilisez les questions suivantes

pour vous aider à prendre votre décision:

Y a-t-il des circonstances dans lesquelles cette règle sera violée si j'entre un

nouveau dossier dans ce tableau?

Cette règle sera-t-elle violée si je n'entre pas de nouvel enregistrement dans

cette table ?

Cette règle sera-t-elle violée si je supprime un enregistrement de cette table ?

Après avoir déterminé quelles actions déclencheront une violation de la règle,

notez-les ; vous les utiliserez à l'étape suivante. Ces informations vous aideront

également à établir cette règle de la manière la plus efficace possible lorsque

vous implémentez la base de données dans vos SGBDR.

Voici un point important à noter : lorsque vous déterminez qu'une règle sera

violée lorsque vous tenterez de supprimer un enregistrement, vous devez

modifier en conséquence la règle de suppression actuelle pour la relation ou

ajouter une nouvelle règle de suppression à la relation.

Vous avez appris au chapitre 10 , « Relations entre tables », que vous n'avez

pas à vous soucier de la suppression d'enregistrements dans la

table enfant d'une relation, car cela ne peut avoir aucun effet négatif. Nous

devons maintenant modifier cette affirmation en indiquant qu'une exception se

produit lors de la suppression d'un dossier dans le tableau des enfants violerait

une règle commerciale requise. Vous gérez cette exception en établissant une

règle de suppression de restriction pour la table des enfants. Faites en

sorte que vous gardez cela à l'esprit lorsque vous déterminez quand une règle
sera testée.

La nouvelle règle commerciale de la base de données de Dance Studio sera

testée lorsque vous tenterai d'insérer un enregistrement dans le tableau des

classes d'instructeurs; Vous pouvez associer un maximum de seulement huit

enregistrements à un instructeur particulier. La règle sera également testée

lorsque vous tentez de supprimer un enregistrement du tableau des classes

d'instructeurs; Chaque instructeur doit être associé à au moins une classe. En

conséquence, vous devez établir une règle de suppression de restriction pour

ce tableau. La figure 11.11 montre les modifications que vous avez apportées

au diagramme de cette relation.

Figure 11.11 Établissement d'une règle de suppression de restriction pour le
tableau des classes d'instructeurs pour soutenir la nouvelle règle commerciale.

Étape 6: Enregistrez la règle sur une feuille de spécifications de règles commerciales

Enfin, remplissez une feuille de spécifications des règles métier pour la règle

métier que vous avez établie à l'étape 4. La figure 11.12 montre la feuille de

spécifications des règles métier complétée pour votre nouvelle règle.

Figure 11.12 Feuille de spécifications des règles métier complétée pour la
nouvelle règle métier.

Tableaux de validation

Lorsque vous définissez des règles métier spécifiques à un champ, il y aura des

cas dans lesquels une règle imposera une contrainte qui définit un ensemble

distinct de valeurs valides pour la plage de valeurs d'un champ donné. (Cela
affecte l'élément Plage de valeurs du champ dans sa spécification de champ.)

Cet ensemble de valeurs comprend généralement un nombre relativement fixe

d'entrées, et les valeurs elles-mêmes changeront rarement. Cependant, si le

nombre d’entrées est plutôt élevé, vous découvrirez peut-être que la mise en

œuvre de cette règle va être légèrement difficile. Par exemple, vous

manquerez probablement de place très rapidement lorsque vous essayez

d'énumérer chacune des valeurs dans l'élément de plage de valeurs sur la

feuille de spécifications de champ, et la mise en œuvre de l'ensemble des

valeurs dans les SGBDR pourrait s'avérer quelque peu compliquée . Vous

pouvez éviter de tels problèmes en stockant toutes les valeurs dans une table

de validation .
Que sont les tables de validation ?

Comme vous l'avez appris au chapitre 3 , « Terminologie », une table de

validation (également appelée table de recherche ) stocke les données que

vous utilisez spécifiquement pour implémenter l'intégrité des données. Vous

n’insérez, ne mettez pas à jour ou ne supprimez pas souvent des

enregistrements dans la table après avoir rempli la table avec les données dont

vous avez besoin. Les tables de validation comprennent généralement (mais

pas toujours) deux champs : le premier fait office de clé primaire et est ce que

vous utiliserez pour vous aider à garantir l'intégrité des données, et le second

est simplement un champ non clé qui stocke un ensemble de valeurs requises.

par un autre champ de la base de données. La figure 11.13 montre deux

exemples de tables de validation.

Figure 11.13 Exemples de tables de validation.

Dans cette section, vous apprendrez à utiliser le champ de clé primaire pour

contribuer à appliquer une règle métier. Vous apprendrez à utiliser le champ

non clé au chapitre 12 , « Vues ».

Utilisation de tables de validation pour prendre en charge les règles

métier

Lorsqu'une règle métier limite la plage de valeurs d'un champ, vous pouvez

appliquer la contrainte à l'aide d'une table de validation ; le champ tirera

ensuite ses valeurs d'un champ approprié dans la table de

validation. L'établissement de ce type de règle implique deux étapes : définir

une relation entre la table parent du champ concerné par la règle et la table de

validation, et apporter une modification à l'élément Plage de valeurs des

spécifications du champ concerné dans la table parent. .

Par exemple, supposons que vous travaillez avec le champ S UPP S TATE d'une

table SUPPLIERS et que vous avez défini la règle métier suivante :

Tout fournisseur que nous utilisons doit être basé dans l’un des 11 États

contigus de l’Ouest, en Alaska ou à Hawaï.

Vous pouvez voir que cette règle impose une contrainte sur la plage de valeurs

du champ S UPP S TATE , les limitant à AK, AZ, CA, CO, HI, ID, MT, NM, NV, OR,

UT, WA et WY. (Selon la règle, vous ne pouvez pas utiliser unfournisseur basé

dans un autre État.) Le moyen le plus simple et le plus efficace d'établir cette

règle est de stocker ces valeurs dans une table de validation appelée STATES,

puis d'utiliser la table de validation comme source de la plage de valeurs du

champ S UPP S TATE ..

Considérez les tableaux de la figure 11.14 . (Remarquez le nouveau symbole

utilisé pour représenter un tableau de validation.) Le tableau des fournisseurs

stocke toutes les données requises sur les fournisseurs engagés par

l'organisation, et le tableau des États est un nouveau tableau de validation qui

stockera les noms et abréviations de la spécifiée États.

Figure 11.14 La table SUPPLIERS et la table de validation STATES.

Votre première tâche consiste à établir une relation entre ces tables. Comme

vous pouvez le constater, il existe une relation un-à-plusieurs entre eux : un

seul enregistrement dans STATES peut être associé à un ou plusieurs

enregistrements dans SUPPLIERS, mais un seul enregistrement dans SUPPLIERS

sera associé à un seul enregistrement dans STATES. Vous savez déjà que vous

établissez une relation un-à-plusieurs en prenant une copie de la clé primaire

de la table parent et en l'incorporant dans la structure de la table enfant où elle

devient une clé étrangère. Bien que le tableau des fournisseurs ait déjà un

champ nommé S Tate SP , vous le remplacerez par le champ S Tate de la table de

validation des états. (Il s'agit d'une modification raisonnable car elle est

conforme aux éléments du champ idéal et est cohérente avec la manière dont

vous établissezrelations un-à-plusieurs.) La figure 11.15 montre le nouveau

diagramme de relations pour ces deux tables.

Figure 11.15 Un diagramme de relations pour les tables SUPPLIERS et

STATES.
Maintenant que le champ S TATE est une clé étrangère dans la table SUPPLIERS,

assurez-vous qu'il est conforme aux éléments d'une clé étrangère (comme

décrit au chapitre 10 ) et définissez sa spécification de champ de la manière

appropriée. Définissez ensuite les caractéristiques de la relation de cette

manière.

• Règle de suppression: définir une règle de suppression de restriction pour

cette relation. Vous ne souhaitez pas supprimer un état de la table STATES

qui est référencé par les enregistrements de la table SUPPLIERS.

• Type de participation : Désignez un type de participation Facultatif pour la

table FOURNISSEURS et un type de participation Obligatoire pour la table

ÉTATS. Bien qu'il ne soit pas nécessaire que la table SUPPLIERS contienne

des enregistrements avant de pouvoir saisir un nouvel enregistrement dans

la table STATES, il doit y avoir au moins un enregistrement dans la table

STATES avant de pouvoir saisir des enregistrements dans la table

SUPPLIERS.

• Degré de participation : Attribuez un (1,1) degré de participation à la table

ÉTATS ; comme vous le savez déjà, il doit y avoir au moins un

enregistrement dans la table STATES avant de pouvoir saisir des

enregistrements dans la table FOURNISSEURS. Affecter un (0, n) degré de

participation pour le tableau des fournisseurs; Tout nombre

d'enregistrements dans ce tableau peut être associé à un enregistrement

particulier dans le tableau des États.

Ensuite, modifiez l'élément Range of Values de la spécification de champ pour

le champ S TATE dans la table SUPPLIERS à l'aide d'un paramètre tel que celui-

ci :

Toute valeur contenue dans le champ S TATE de la table STATES.

La figure 11.16 montre les paramètres que vous avez créés dans la catégorie

des éléments logiques de la feuille de spécifications de champ pour ce champ.

Figure 11.16 Définition de la catégorie Éléments logiques pour le champ de

clé étrangère S TATE dans la table SUPPLIERS.

Vous devez maintenant décider quelles actions testent la règle. Lorsque vous

utilisez une table de validation pour appliquer une règle commerciale, vous

souhaitez généralement tester la règle lorsqu'un utilisateur tente d' insérer une

nouvelle valeur dans le champ ou de mettre à jour une valeur existante dans le

champ. Dans les deux cas, une violation se produira lorsque l'utilisateur tentera

de saisir une valeur qui n'existe pas dans la table de validation.

Enfin, remplissez une feuille de spécifications de règles commerciales pour la

règle d'entreprise que vous venez d'établir. Assurez-vous d'indiquer les

modifications que vous avez apportées au domaine et à la nouvelle relation. La

figure 11.17 montre la feuille de spécifications de règle commerciale terminée

pour votre nouvelle règle.

Figure 11.17 Feuille de spécifications des règles métier complétée pour la
nouvelle règle métier.

Examiner les feuilles de spécifications des règles

commerciales

Après avoir établi les règles commerciales que vous croyez appropriées, passez

en revue leurs feuilles de spécification. Examinez attentivement chaque fiche

technique et assurez-vous que vous avez correctement établi la règle et que

vous avez clairement marqué toutes les zones appropriées sur la feuille. Si

vous trouvez une erreur, effectuez les modifications nécessaires et révisez-la

une fois de plus. Répétez ce processus jusqu'à ce que vous ayez examiné

chaque règle métier.

Les règles métier sont un élément important de la base de données. Ils

contribuent à l’intégrité globale des données et imposent des contraintes

d’intégrité spécifiques à l’organisation. Comme vous l'avez vu, ces règles

contribuent à assurer la validité et la cohérence des données selon la manière

dont l'organisation fonctionne ou mène ses activités. De plus, ces règles

finiront par influencer la manière dont vous implémentez la base de données

dans votre SGBDR et la manière dont vous concevez et développez des

programmes d'application pour l'utilisateur final pour la base de données.

Il est important de comprendre que vous revisiterez ces règles assez

souvent. Par exemple, lorsque vous examinez la structure finale, vous pouvez

déterminer que des règles métier supplémentaires sont nécessaires. Vous

découvrirez peut-être que certaines règles ne fourniront pas les résultats que

vous aviez initialement envisagés, vous devrez donc les modifier. Il vous est

également possible de déterminer que certaines règles ne sont finalement pas

nécessaires. (Dans ce cas, veillez absolument à examiner attentivement les

règles avant de les supprimer.)

Gardez à l’esprit que les règles métier que vous définissez maintenant

nécessiteront forcément des modifications à l’avenir ; vous devrez

probablement ajouter des règles métier en temps utile en raison de

changements dans la manière dont l'organisation fonctionne ou mène ses

activités. La nécessité de modifier les règles métier existantes ou d’en

développer de nouvelles est tout à fait normale : l’organisation grandit et mûrit

inévitablement, tout comme la manière dont elle évolue.dans lequel il agit ou

réagit à des forces extérieures. Ces forces affectent la manière dont

l'organisation perçoit et utilise ses données, ce qui, à son tour, modifie la

nature des exigences des règles métier de l'organisation.

La tâche de définition et d'établissement de règles métier est continue, comme

tant d'autres tâches au sein du processus de conception de bases de

données. Ne vous découragez pas si vous devez effectuer cette tâche plusieurs

fois. Vos efforts porteront de grands fruits à long terme.

EXEMPLE : DÉFINIR ET ÉTABLIR DES RÈGLES COMMERCIALES

Il est maintenant temps d'établir des règles métier pour la base de données de

Mike. Vous planifiez une réunion avec Mike et son équipe pour examiner les

tables et les relations dans leur base de données. La première chose à faire est

de définir et d’établir des règles métier spécifiques au domaine.

Vous commencez le processus en examinant le tableau des produits. Lorsque

vous examinez chaque champ, vous déterminez si cela nécessite des

contraintes. Lorsque vous arrivez sur le champ C Ategory , vous vous souvenez

qu'il y avait une question concernant sa gamme de valeurs. (Reportez-vous à

l'exemple du chapitre 9 , « Spécifications de champ ».) Vous discutez encore

une fois de cette question avec Mike et son personnel, et vous vous êtes enfin

consensuel sur une liste distincte de catégories. Mike décide alors que les

valeurs du champ Category devraient être limitées à ceux de cette liste pour

s'assurer que le personnel n'invente pas arbitrairement de nouvelles

catégories. Sur la base de la décision de Mike, vous définissez une règle

commerciale appropriée pour établir la contrainte:

Les catégories de produits invalides ne sont pas autorisées.

Un certain nombre d'éléments figurent dans la liste des catégories possibles.

Vous décidez donc que la meilleure façon d'établir cette règle est d'utiliser une

table de validation. Toicréez une nouvelle table appelée CATEGORIES, puis

établissez une relation entre celle-ci et la table PRODUCTS. Vous allez ensuite

schématiser la relation et définir ses caractéristiques de manière

appropriée. La figure 11.18 montre les résultats de votre travail.

Figure 11.18 Le diagramme de relations pour les tables PRODUITS et
CATÉGORIES.

Voici les paramètres que vous avez utilisés pour les caractéristiques de la

relation.

• Il existe une règle de suppression de restriction pour la relation.

• Le tableau des catégories a un type de participation obligatoire .

• Le tableau des produits a un type de participation facultatif .

• Le tableau des catégories a un (1,1) degré de participation.

• Le tableau des produits a un (0, n) degré de participation.

N'oubliez pas qu'en établissant cette relation, vous avez remplacé le

champ Category existant dans le tableau des produits par une copie du champ

d'identification C Ategory à partir du tableau des nouvelles catégories. Vous devez

maintenant vous assurer que le champ d'identification C Ategory dans le tableau

des produits est conforme aux éléments d'une clé étrangère, puis apporter les

modifications appropriées à sa spécification de champ. Enfin, définissez

l'élément de plage de valeurs du champ sur quelque chose comme celui-ci:

Toute valeur dans le champ d'ID C Ategory dans le tableau des catégories.

La figure 11.19 montre les paramètres que vous avez créés à la catégorie des

éléments logiques des spécifications de champ pour le champ d'identification

de la category dans le tableau des produits.

Figure 11.19 Paramètres des éléments logiques pour le champ de clé
étrangère C ATEGORY ID dans la table PRODUCTS.

Vous devez maintenant décider quand la règle doit être testée. Comme vous le

savez déjà, vous souhaitez généralement tester une règle établie avec une

table de validation si l'utilisateur tente d'insérer une valeur dans le champ ou

de mettre à jour une valeur existante dans le champ.

Enfin, vous complétez une feuille de spécifications de règles commerciales pour

cette nouvelle règle commerciale. Cette fiche de spécification reflétera les

modifications que vous avez apportées aux spécifications du champ pour le

champ d'identification C Ategory , ainsi que les caractéristiques de la relation

entre les catégories et les tableaux de produits. La figure 11.20 montre la

feuille de spécifications des règles commerciales terminée.

Figure 11.20 Feuille de spécifications des règles métier complétée pour la
nouvelle règle métier.

Vous répétez ce processus pour les champs restants de cette table et pour les

champs des tables restantes. Une fois que vous avez terminé, vous passez à la

tâche suivante.

La prochaine étape consiste à établir des règles commerciales spécifiques à la

relation. Vous commencez par examiner la relation entre les tables EMPLOYEES

et INVOICES, puis vous examinez le diagramme de relation pour déterminer si

la relation nécessite des contraintes. Tout semble être en ordre, vous passez

donc à la relation entre les tables VENDORS et PRODUCTS. La figure

11.21 montre le diagramme de relations pour ces tables.

Figure 11.21 Le diagramme de relation pour les tables VENDORS et

PRODUCTS.
Alors que vous et Mike discutez si vous devez imposer des contraintes à cette

relation, Mike détermine qu'il devrait y avoir une contrainte sur le tableau des

produits. Il veut s'assurer que chaque fournisseur de la table des vendeurs est

associé à au moins un produit; Il estime qu'il n'est pas nécessaire de conserver

des données sur un fournisseur qui ne lui fournit aucun produit. Vous définissez

donc la règle commerciale suivante pour cette contrainte:

Chaque vendeur doit fournir au moins un produit.

Vous allez maintenant établir la règle en modifiant les caractéristiques de

relation appropriées. Vous commencez par désigner un type de participation

obligatoire et attribuer un (1, n) degré de participation aux

produitstableau. Vous définissez ensuite une règle Restreindre la suppression

pour la relation basée sur la table PRODUCTS ; cela vous évitera de supprimer

accidentellement le seul produit associé à un fournisseur donné. La figure

11.22 montre les résultats de vos modifications.

Figure 11.22 Le diagramme de relation révisé pour les tables VENDORS et

PRODUCTS.
Vous savez déjà que ce type de règle métier sera testé lorsqu'un utilisateur

tentera d'insérer ou de supprimer un enregistrement dans la table PRODUITS.

Vous devez donc terminer ce processus en remplissant une feuille de

spécifications de règle métier pour cette règle. La figure 11.23 montre la fiche

technique complétée.
Figure 11.23 Une feuille de spécifications de règles commerciales terminée.

Répétez maintenant ce processus pour les relations restantes. Lorsque vous

avez terminé, le processus est terminé et vous êtes prêt pour la prochaine

étape du processus de conception de la base de données.

Résumé

Ce chapitre s'est ouvert avec une définition des règles commerciales. Vous

avez appris qu'une règle d'entreprise est une contrainte imposée sur un

domaine ou une relation basée sur la façon dont l'organisation perçoit et utilise

ses données et qu'elle dérive de la manière dont l'organisation fonctionne ou

mène ses activités. Vous savez maintenant qu'il existe deux principaux types

de règles métier: orientée vers la base de données et orienté vers

l'application. Bien que nous nous concentrions ici sur les règles métier
orientées base de données, vous savez que vous pouvez au moins enregistrer

les éléments de base des règles métier orientées application pour les utiliser

ultérieurement dans le processus de mise en œuvre.

Vous avez ensuite appris que les règles commerciales axées sur la base de

données sont divisées en deux catégories: les règles commerciales spécifiques

au champ , qui affectent les éléments d'une spécification de champ pour un

champ particulier; et les règles commerciales spécifiques à la relation , qui
affectent les caractéristiques d'une relation.

Le chapitre s'est poursuivi avec une discussion sur la définition et

l'établissement de règles commerciales. Ici, vous avez appris que vous

travaillez avec les utilisateurs et la direction pour définir les règles métier

requises par l'organisation. Vous avez également appris qu'il est préférable

d'établir d'abord les règles commerciales spécifiques au domaine, suivies des

règles commerciales spécifiques aux relations.

Ensuite, vous avez appris les étapes nécessaires pour définir et établir chaque

type de règle d'entreprise. Vous savez maintenant que, en général, vous

travaillez avec un domaine ou une relation, passez en revue le domaine ou la

relation à la lumière de la règle pour déterminer si des contraintes sont

nécessaires, définissez la règle commerciale appropriée, établissez la règle en

modifiant les éléments de spécification de champ appropriés ou les

caractéristiques de la relation, décidez quelles actions testent la règle, puis

complétez une feuille de spécifications de règle commerciale pour la règle.

Le chapitre s'est poursuivi avec une discussion sur les éléments de la feuille de

spécifications de règles commerciales et comment chaque élément de la feuille

est défini. L'utilisation de feuilles de spécifications de règles commerciales vous

permet de documenter toutes vos règles et vous fournit une méthode standard

pour les enregistrer et les examiner.

Nous avons fermé le chapitre en discutant des tables de validation. Vous avez

appris que vous pouvez créer et utiliser un tableau de validation pour soutenir

une règle commerciale qui limite la plage de valeurs pour un champ

particulier. De cette manière, le tableau de validation aide à appliquer

l'intégrité des données. Vous avez également appris que vous devez établir de

nouvelles relations lorsque vous utilisez des tables de validation et que ces

relations ont les mêmes types de caractéristiques que tous les autres types de

relations dans la base de données.

Questions de révision

1. Qu'est-ce qu'une règle d'entreprise?

2. Nommez les deux principaux types de règles commerciales.

3. Pouvez-vous établir des règles commerciales orientées vers

l'application dans la conception logique de la base de données?

4. Quelles sont les deux catégories de règles commerciales axées sur la base

de données ?

5. Qu'est-ce qu'une règle commerciale spécifique au terrain?

6. Quand une règle d'entreprise est-elle testée?

7. Comment documentez-vous une règle commerciale?

8. Énoncez deux avantages que la feuille de spécifications de règles

commerciales fournit.

9. Quel est le but de la section des mesures prises d'une feuille de

spécifications de règles commerciales?

10. Quel est le but d'un tableau de validation?

11. Quelle est la structure typique d'un tableau de validation?

12. Quelle est l'association entre une règle d'entreprise et un tableau de

tvalidation?
a
b
13.
l Pourquoi devriez-vous consulter toutes vos feuilles de spécifications de
e
règles commerciales terminées?

d
re
dqP
ouaes
serc
uahm
a
em
èrt
itc
èrh
re
es
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
11. Règles commerciales
12. Vues
13. Examen de l'intégrité des données
2h 39min restant

12

Vues

Il n’existe aucun objet sur Terre qui ne puisse être observé d’un point de vue
cosmique.

—F YODOR MIKHAYLOVITCH D OSTOYEVSKY _

Sujets abordés dans ce chapitre

Que sont les vues ?

Anatomie d'une vue

Détermination et définition des vues

Exemple : détermination et définition de vues

Résumé

Questions de révision

Que sont les vues ?

Comme vous l'avez appris au chapitre 3 , « Terminologie », une vue est

une table virtuelle composée de champs provenant d'une ou plusieurs tables

de la base de données ; il peut également inclure des champs provenant

d'autres vues. Les tables qui composent une vue donnée sont appelées tables

de base de la vue. Une vue est « virtuelle » car elle extrait des données de
tables de base plutôt que de stocker des données seules. En fait, la seule

information sur une vue stockée dans la base de données est sa structure ; le

SGBDR reconstruit et « repeuple » la vue chaque fois que vous y accédez d'une

manière ou d'une autre. De nombreux programmes SGBDR majeurs prennent

en charge les vues et les appellent requêtes enregistrées. Votre programme

SGBDR spécifique déterminera si vous faites référence à cet objet en tant que

requête ou vue.

Note
Bien que tous les principaux fournisseurs de bases de données prennent en

charge la vue que je viens de décrire, plusieurs fournisseurs prennent en

charge ce que l'on appelle une vue indexée (ou matérialisée ). Une vue

indexée est différente d'une vue standard dans la mesure où elle stocke des

données et ses champs peuvent être indexés pour améliorer la vitesse à

laquelle le SGBDR traite les données de la vue. Une discussion complète sur les

vues indexées dépasse le cadre de ce livre car il s'agit d'un problème

d'implémentation spécifique au fournisseur. Cependant, vous devriez

approfondir vos recherches sur ce sujet si vous travaillez avec un programme

SGBDR client/serveur ou mainframe.

Les vues vous permettent de voir les informations de votre base de données

sous de nombreux aspects différents, vous offrant ainsi une grande flexibilité

lorsque vous travaillez avec vos données. Vous pouvez créer des vues de

différentes manières, et elles sont particulièrement utiles lorsque vous les

basez sur plusieurs tables liées.

Il existe plusieurs raisons pour lesquelles vous devez définir et utiliser des vues

dans votre base de données :

• Vous pouvez les utiliser pour travailler simultanément avec les données de

plusieurs tables. Au cours du processus de conception de la base de

données, vous avez établi des relations entre différentes paires de tables

ayant des relations un-à-plusieurs ou plusieurs-à-plusieurs. (Rappelez-vous

que vous avez résolu les relations plusieurs-à-plusieurs via des tables de

liaison.) Une vue fournit le mécanisme qui vous permet de travailler

simultanément avec les données de deux ou plusieurs tables liées.

• Ils reflètent les informations les plus récentes. Étant donné que le SGBDR

reconstruit et remplit à nouveau la vue à chaque fois que vous y accédez,

les informations affichées par la vue présentent les modifications les plus

récentes apportées aux données dans ses tables de base.

• Vous pouvez les personnaliser selon les besoins spécifiques d'un individu ou

d'un groupe d'individus. Vous pouvez créer une vue adaptée à n'importe
quel ensemble d'exigences, par exemple fournir les données d'un rapport

particulier ou fournir un moyen d'examiner des informations spécifiques

communes à plusieurs services d'une organisation.

• Vous pouvez les utiliser pour aider à appliquer l'intégrité des données. Vous

pouvez définir une vue de validation qui fonctionne de la même manière

qu'une table de validation - son objectif est de fournir une plage de valeurs

valide pour un champ donné dans la base de données.

• Vous pouvez les utiliser à des fins de sécurité ou de confidentialité. Vous

pouvez déterminer quelles données sont disponibles pour un utilisateur ou

un groupe d'utilisateurs particulier en définissant une vue sur des champs

sélectionnés à partir des tables de base de la vue.

Définissez vos vues avec soin et habileté, et elles deviendront un atout

précieux une fois que vous aurez implémenté la base de données dans votre

SGBDR.

Anatomie d'une vue

Vous pouvez définir trois types de vues ( données, agrégat et validation )

lorsque vous concevez la structure logique de la base de données et deux

types de vues ( matérialisée et partitionnée ) lorsque vous implémentez votre

base de données dans un SGBDR. La capacité à définir ces deux derniers types

de vues et la manière dont vous le faites dépendent fortement de votre SGBDR

et dépassent donc le cadre de ce livre. Nous concentrerons donc notre

attention sur les trois premiers types de vues.

Affichage des données

Vous utilisez ce type de vue pour examiner et manipuler les données d'une

seule table de base ou de plusieurs tables de base.

Vue de données à table unique

Bien que vous puissiez utiliser tous les champs de la table de base pour créer

ce type de vue, vous utiliserez généralement uniquement les champs

sélectionnés. (Créer une vue utilisant tous les champs de la table de base

produirait simplement une copie virtuelle de la table de base.) Par exemple,

supposons que vous souhaitiez créer une liste de noms et de numéros de

téléphone d'employés accessibles à tous les membres de l'organisation. Vous

pouvez créer une vue LISTE TÉLÉPHONIQUE DES EMPLOYÉS basée sur la table

EMPLOYEES en utilisant uniquement les champs E MPLOYEE ID ,E MP FIRST N AME ,

E MP L AST N AME et E MP T HONE N UMBER . La figure 12.1 montre un diagramme de

cette vue particulière. (Notez le nouveau symbole utilisé pour indiquer une

vue.)
Figure 12.1 La vue LISTE TÉLÉPHONIQUE DES EMPLOYÉS.

Votre SGBDR reconstruira et remplira à nouveau la vue LISTE TÉLÉPHONIQUE

DES EMPLOYÉS à chaque fois que vous y accéderez, et la vue reflétera les

dernières modifications que vous avez apportées aux données de la table

EMPLOYEES. La figure 12.2 montre comment un SGBDR affiche généralement

les données dans une vue.Notez que l’apparence de la vue est assez similaire à

celle d’un tableau ; c'est encore une autre raison pour laquelle une vue est

connue sous le nom de « table virtuelle ».

Figure 12.2 Informations de la vue LISTE TÉLÉPHONIQUE DES EMPLOYÉS.

Vous pouvez modifier les données dans une vue de données à table unique à

tout moment, et les modifications que vous apportez seront transmises à

travers la vue et dans la table de base. Gardez toutefois à l’esprit que les

spécifications des champs et les règles métier détermineront les types de

modifications que vous pourrez apporter aux données. Par exemple, vous ne

pourrez pas supprimer un nom de famille dans la vue LISTE TÉLÉPHONIQUE

DES EMPLOYÉS si l'élément Prise en charge des valeurs nulles de la

spécification du champ E MP L AST N AME est défini sur « Aucune valeur nulle ».

Note

La mise en œuvre de View varie dans une certaine mesure selon la plupart des

logiciels SGBDR. Assurez-vous d'examiner la documentation de votre SGBDR

pour déterminer dans quelle mesure le SGBDR prend en charge les vues et

quels types de contraintes il impose (le cas échéant) lors de la modification des

données dans une vue.

Affichage des données multitables

Comme je l'ai mentionné au début de cette section, vous pouvez définir une

vue de données à l'aide de deux tables ou plus. La seule exigence est que les

tables que vous utilisez pour créer la vue doivent entretenir une relation les

unes avec les autres ; cela permet de garantir que les informations présentées

par la vue sont à la fois valides et significatives. Par exemple, supposons que

vous conceviez une base de données pour uncollège communautaire local et

que les tableaux de la figure 12.3 font partie de la base de données. Vous

venez de décider que vous devez créer une vue appelée CLASS ROSTER qui

affiche le nom de chaque classe et les noms des étudiants actuellement

inscrits pour y assister. Ce sera une tâche facile à réaliser car vous pouvez

utiliser les trois tableaux comme base de la vue ; ils contiennent les champs

dont vous avez besoin pour définir la vue et ils entretiennent une relation les

uns avec les autres.

Figure 12.3 Tableaux de base pour la vue CLASS ROSTER.

Vous définissez maintenant la vue CLASS ROSTER en utilisant le champ

C LASS N AME de la table CLASSES et les champs S TUD FIRST N AME et

S TUD L AST N AME de la table STUDENTS. Les noms d'élèves appropriés

apparaîtront pour chaque classe car les CLASSES et les ÉTUDIANTS sont liés (et

donc connectés) via la table de liaison CLASSES D'ÉTUDIANTS. La figure

12.4 montre le diagramme de la vue CLASS ROSTER. Notez qu’aucune

modification n’a été apportée aux tables de base.

Figure 12.4 Le diagramme de la vue CLASS ROSTER.

Chaque fois que vous accédez à la vue CLASS ROSTER, le SGBDR le

reconstruira et le repeuplera en utilisant les données les plus récentes des

tables de base de la vue. La figure 12.5 montre un échantillon des données de

la vue.

Figure 12.5 Un échantillon partiel de données de la vue CLASS ROSTER.

Vous pouvez modifier certaines données dans une vue de données multitable à

tout moment, et les modifications que vous apporterez seront transmises à

travers la vue et aux tables de base. Bien évidemment, vous ne pouvez pas

modifier la valeur des clés primaires que vous incorporez à partir des tables de

base. Comme dans le cas d'une vue à table unique, les spécifications des

champs et les règles métier détermineront les types de modifications que vous

pouvez apporter aux données. (Encore une fois, assurez-vous de vérifier la

documentation de votre SGBDR pour connaître toute autre contrainte qu'il

pourrait imposer à vos vues.)

Les données redondantes dans la vue CLASS ROSTER (que vous auriez dû

remarquer) sont le résultat de la fusion d'un enregistrement de la table

CLASSES avec deux ou plusieurs enregistrements de la table STUDENTS ; le

nombre de fois qu'un nom de classe particulier apparaît est égal au nombre

d'étudiants inscrits pour assister à ce cours. Cette redondance apparente est

acceptable car les données ne sont pas physiquement stockées dans la vue ; il

est plutôt extrait des tables de base de la vue, où il est stocké conformément

aux règles de conception appropriée de la base de données. Les SGBDR

affichent généralement les données des vues multitables de cette manière.

Un autre point à noter est qu'une vue de données ne contient pas sa propre clé

primaire. Il lui manque une clé primaire car ce n’est pas une table ; une vraie

table stocke les données et nécessite une clé primaire pour servir d'identifiant

unique pour chacun de ses enregistrements. Vous pouvez incorporer une clé

primaire de n'importe laquelle (ou de toutes) des tables de base dans la vue,

cependant, lorsque vous déterminez qu'elle contribuera aux informations

fournies par la vue.

Note
Pour éviter toute ambiguïté ou confusion inutile, assurez-vous de ne pas avoir

d'indicateurs clés primaires dans le symbole de vue lorsque vous schématisez

une vue de données .

Vue globale

Vous utilisez ce type de vue pour afficher des informations produites en

agrégeant un ensemble particulier de données d'une manière

spécifique. Comme pour une vue de données,vous pouvez définir une vue

agrégée à l'aide d'une ou plusieurs tables de base. Vous pouvez ensuite inclure

un ou plusieurs champs calculés qui intègrent les fonctions qui agrègent les

données et un ou plusieurs champs de données (tirés des tables de base de la

vue) pour regrouper les données agrégées. Somme, Moyenne (moyenne

arithmétique), Minimum, Maximum et Nombre sont les fonctions d'agrégation

les plus courantes que vous pouvez appliquer à un ensemble de données, et

tous les principaux SGBDR les prennent en charge.

Supposons que vous vouliez savoir combien d'élèves sont inscrits dans chaque

classe et que vous utilisiez les tableaux de l'exemple d'école présenté dans la

figure 12.3 . Votre première impulsion est de définir une vue de données

appelée CLASS REGISTRATION qui fournira les informations dont vous avez

besoin pour répondre à votre question. Ainsi, vous utilisez le champ

C LASS N AME de la table CLASSES et le champ S TUDENT ID de la table STUDENT

CLASSES pour créer la vue. La figure 12.6 montre un diagramme pour la

nouvelle vue ENREGISTREMENT DE CLASSE.

Figure 12.6 Diagramme de vue pour la nouvelle vue INSCRIPTION DE CLASSE.

Vous accédez maintenant à la vue afin de pouvoir répondre à votre

question. La figure 12.7 montre un échantillon partiel des données dans la vue.
Figure 12.7 Un échantillon partiel de données de la vue CLASS
REGISTRATION.

Pour répondre à votre question, vous devez maintenant compter chaque

instance d'un nom de classe donné afin de pouvoir déterminer combien

d'élèves sont inscrits dans cette classe. Imaginez le travail qui vous attend : ce

ne sera pas une tâche facile ! Plutôt que de faire tout ce travail fastidieux, vous

pouvez répondre à votre question assez facilement (et plus efficacement) en

utilisant une vue globale.

Il n'est pas nécessaire de définir une nouvelle vue car vous pouvez modifier

celle que vous avez actuellement. Supprimez le champ ID ÉTUDIANT de la vue et

remplacez-le par un champ calculé appelé T OTAL ÉTUDIANTS INSCRITS qui compte le

nombre d' élèves par classe. (Lorsque vous travaillez avec un champ calculé,

assurez-vous de lui donner un nom significatif et qui le distinguera des autres

champs calculés dans la vue.) Le champ calculé utilisera une fonction Count

pour compter le nombre d' ID D' ÉTUDIANT . S dans la table STUDENT CLASSES qui

sont associés à chaque ID C LASS dans la table STUDENT CLASSES. (Plus tard,

vous apprendrez à documenter un(voir et enregistrer l'expression que le champ

calculé utilisera.) La figure 12.8 montre le diagramme révisé pour la vue

INSCRIPTION DE CLASSE.

Figure 12.8 Diagramme révisé pour la vue INSCRIPTION DE CLASSE.

Comme ce fut le cas pour la vue des données, le SGBDR reconstruira et

remplira à nouveau la vue CLASS REGISTRATION à chaque fois que vous y

accéderez, en utilisant les données les plus récentes des tables de base de la

vue. La figure 12.9 montre un échantillon des données de la vue.

Figure 12.9 Un échantillon de données de la vue révisée ENREGISTREMENT

DE CLASSE.

Il y a trois choses à noter à propos de ce point de vue :

1. Le champ T OTAL DES ÉTUDIANTS INSCRITS affiche un nombre unique pour

chaque nom de classe, qui représente le nombre total d'étudiants inscrits

dans cette classe .

2. La redondance dans le champ C LASS N AME a été éliminée ; toutes les

instances d'un nom de classe donné ont été regroupées en une seule

instance. En conséquence, C LASS N AME est désormais un champ de

regroupement et ses valeurs ne peuvent en aucun cas être modifiées.

Note
 Tous les champs de données d'une vue agrégée sont des champs de

regroupement.

3. Étant donné qu’une vue agrégée est entièrement composée de champs de

regroupement et de champs calculés, vous ne pouvez modifier aucune de

ses données.

Une vue globale est particulièrement utile comme base d'un rapport ou comme

moyen de fournir divers types d'informations statistiques. Vous apprendrez plus

tard que vous pouvez appliquer des critères de filtrage à cette vue (ou à toute

autre) pour contrôler et restreindre les données affichées par la vue.

Vue de validation

Une vue de validation est similaire à un tableau de validation en ce qu'il peut

aider à implémenter l'intégrité des données. Lorsqu'une règle métier limite la

plage de valeurs d'un champ particulier, vous pouvez appliquer la contrainte

aussi facilement avec une vue de validation qu'avec une table de validation. La

différence entre les deux réside dans leur construction : une table de validation

stocke ses propres données, tandis qu'une vue de validation extrait les

données de sa base.les tables. Bien que vous puissiez définir une vue de

validation à l'aide d'une ou plusieurs tables de base, vous définirez

généralement une table de validation à l'aide d'une seule table de base et

incorporerez uniquement deux ou trois champs de la table de base. (Cette

structure est assez similaire à celle d'une table de validation.)

Par exemple, disons que vous concevez une base de données pour un petit

entrepreneur et que vous travaillez avec les tableaux de la figure 12.10 .

Figure 12.10 Tableaux d'une base de données pour un petit entrepreneur.

Comme vous pouvez le voir, le champ d'ID S UBContractor dans le tableau des

sous-traitants fournit la plage de valeurs pour le champ d'ID S ubContractor dans

le tableau des sous-traitants du projet. (Rappelez-vous qu'une clé étrangère

tire ses valeurs de la clé primaire à laquelle elle fait référence.) Vous avez

toutefois décidé de restreindre l'accès des utilisateurs à certains champs de la

table SOUS-TRAITANTS ; vous avez décidé que les seuls champs auxquels les

utilisateurs devraient pouvoir accéder sont les champs ID SOUS- TRAITANT ,

SCN AME , SCP HONE NUMBER et S CEMAIL . Ainsi, vous définissez une vue de

validation appelée sous-traitants approuvés qui incorporera ces champs et

fourniront toujours la plage de valeurs pour le champ d'ID S ubContractor dans le

tableau des sous-traitants du projet. La figure 12.11 montre un diagramme

révisé des tables, y compris la nouvelle vue.

Figure 12.11 Diagramme de table révisé; Notez la nouvelle vue de sous-
traitants approuvée.

La vue SOUS-TRAITANTS APPROUVÉS permet désormais aux utilisateurs

d'accéder uniquement aux champs que vous avez indiqués et fournit la plage

de valeurs appropriée pour le champ ID SOUS- TRAITANT dans la table SOUS-

TRAITANTS DU PROJET. De plus, la vue appliquera toujours les caractéristiques

de relation qui existent pour la table SOUS-TRAITANTS car il s'agit (comme vous

vous en souviendrez) de la table de base de la vue.

Détermination et définition des vues

Vous avez probablement déjà réalisé que les vues peuvent constituer un atout

considérable pour la base de données. Au cours de cette étape du processus

de conception de la base de données, vous définissez un ensemble

fondamental de vues pour la base de données. Votre définition des vues ne

s'arrêtera pas là ; Vous définissez probablement plus de vues lorsque vous

implémenterez la base de données au sein de vos SGBDR et que vous créez

vos programmes d'application de l'utilisateur final. Dans ces cas, vous utiliserez

les vues comme un outil pour prendre en charge des aspects particuliers du

programme d'implémentation ou d'application. Cependant, les vues que vous

définissez pendant le processus de conception de la base de données se

concentreront strictement sur l'accès aux données et les problèmes de

récupération des informations.

Travailler avec les utilisateurs et la gestion

Vous travaillerez à nouveau avec le groupe représentatif d'utilisateurs et de

direction de l'organisation pour identifier les types de vues dont l'organisation a

besoin. Après avoir identifié ces points de vue, vous les établirez et les

documenterez, puis vous et le groupe examinerez les points de vue pour vous

assurer qu'ils sont correctement définis.

Avant de mener votre première réunion avec le groupe, passez en revue les

notes que vous avez prises tout au long du processus de conception. Votre

objectif est d’avoir une idée des types de vues dont l’organisation pourrait

avoir besoin. Presque toutes les organisations consacrent beaucoup de temps à

produire et à lire des rapports. Vous devez donc vous concentrer sur cet aspect

de vos notes. Vous devez également examiner les échantillons de rapport que

vous avez rassemblés au cours du processus d'analyse.

Lorsque vous et le groupe vous rencontrez, tenez compte des points suivants

pour vous aider à identifier les exigences en matière de vue.

• Passez en revue vos notes avec le groupe. Dans de nombreux cas, parler

d'un sujet spécifique suscitera une idée pour une vue nouvelle ou

requise. Par exemple, quelqu'un peut réaliser un besoin de vue lors d'une

discussion sur les objectifs de la mission.

• Passez en revue les exemples de saisie de données, de rapports et de

présentations que vous avez rassemblés au cours des premières étapes du

processus de conception. L’examen de ces échantillons, en particulier des
rapports de type résumé, pourrait facilement mettre en lumière la nécessité

de certains types de points de vue.

• Examinez les tableaux et les sujets qu’ils représentent. Certaines personnes

du groupe peuvent identifier le besoin d’un point de vue basé uniquement

sur un sujet spécifique. Si quelqu'un mentionne un sujet, tel que les

employés, quelqu'un d'autre peut dire : « Nous avons absolument besoin

d'une vue qui restreint certaines données des employés pour des raisons de

confidentialité. »

• Analysez les relations entre les tables. Vous allez très probablement

identifier un certain nombre de vues multiples que vous devriez créer pour

de nombreuses relations. Plusieurs de ces vues coïncidront avec les vues

que vous avez identifiées pour les échantillons de rapport.

• Étudiez les règles commerciales. Comme vous le savez déjà, vous pouvez

utiliser une vue de validation pour appliquer une règle imposant une

contrainte sur la plage de valeurs d'un champ particulier.

Vous et le groupe devriez être en mesure d’identifier un certain nombre de

points de vue en parcourant les éléments de cette liste. Après avoir identifié

autant de vues requises que possible, votre tâche suivante consiste à les

définir.
Définir des vues

Vous allez maintenant définir chaque vue que vous avez identifiée à l'aide des

tables et des champs appropriés. Examinez les diagrammes de relations pour

identifier les tables et les champs dont vous avez besoin pour la structure de la

vue. Lorsque vous avez déterminé ce dont vous avez besoin, définissez la vue

et enregistrez-la dans un diagramme de vue.

Par exemple, supposons que vous ayez déterminé que vous pouvez utiliser une

vue pour le rapport présenté dans la figure 12.12 ; le nom de la nouvelle vue

sera LISTE D'APPELS CLIENTS.

Figure 12.12 Exemple de rapport nécessitant une vue.

Les notes que vous avez prises tout au long du processus de conception

redeviennent utiles. Vous avez examiné ce rapport au cours de la phase

d'analyse du processus de conception et vous avez noté que ce rapport

représente des informations sur les clients et leurs commandes ; c'est à partir

des données de commande que vous pouvez déterminer quand un client donné

a effectué son dernier achat. Maintenant, examinez le diagramme de relation

pour les tables CUSTOMERS et ORDERS ; vous utiliserez les champs de ces

tables pour créer la vue LISTE D'APPELS CLIENTS. La figure 12.13 montre le

diagramme de relations pour ces tables.

Figure 12.13 Diagramme de relations pour les tables CLIENTS et

COMMANDES.
Après avoir examiné le diagramme de relations, vous déterminez que vous

devez utiliser cinq champs pour créer cette vue : C UST F IRST N AME ,

C UST L AST N AME ,NUMÉRO DE TÉLÉPHONE DU CLIENT et VILLE DU DÉTAIL dans la table

CLIENTS et DATE DE LA COMMANDE dans la table COMMANDES . Vous définissez

maintenant la vue LISTE D'APPELS CLIENTS en affectant les champs à la vue,

puis en les enregistrant dans un diagramme de vue. Lorsque vous avez

terminé, votre diagramme devrait ressembler à celui de la figure 12.14 .

Figure 12.14 Diagramme de vue pour la vue LISTE D'APPELS CLIENT.

Utilisation des champs calculés le cas échéant

Plus tôt dans le processus de conception de la base de données, vous avez

appris que les tables ne pouvaient pas contenir de champs calculés pour

plusieurs bonnes raisons. Mais l’une des caractéristiques d’une vue qui la rend

si utile est qu’elle peut contenir des champs calculés. Rappelez-vous que les

champs calculés afficheront le résultat deune fonction de concaténation,

d'expression ou d'agrégation ; cela en fait une structure extrêmement flexible à

inclure dans une vue.

Par exemple, considérons la nouvelle vue LISTE D'APPELS CLIENTS. Bien que

vous disposiez des champs dont vous avez besoin pour la vue, vous devrez

apporter une modification mineure à la vue afin qu'elle puisse afficher les

données appropriées. L'une des exigences de cette vue est qu'elle doit afficher

la date du dernier achat effectué par chaque client. Pour récupérer et afficher

la date appropriée, vous devrez ajouter un champ calculé à la vue. Ce champ

utilisera la fonction Maximum [communément appelée Max()] pour récupérer la

date correcte du champ O RDER D ATE . Nommez le nouveau

champ DATE DU DERNIER ACHAT et ajoutez-le au diagramme de vue LISTE

D'APPELS CLIENT . (Vous n'avez plus besoin du champ O RDER D ATE dans la vue,

vous pouvez donc le supprimer de la structure de la vue.) C'est l'expression

que vous utiliserez dans le champ calculé pour récupérer la date appropriée :

Max (Date de commande)

Plus loin dans cette section, vous apprendrez où et comment enregistrer cette

expression.

Note
Assurez-vous de vous référer à la documentation de votre RDMBS pour

déterminer la syntaxe correcte pour cette fonction et toutes les autres

fonctions utilisées dans ce chapitre.

Un autre champ calculé que vous pouvez inclure dans cette vue est celui qui affiche le nom

complet du client en concaténant C UST FIRST N AME et C UST L AST N AME . Dites,

par exemple, que vous souhaitez afficher le nom du client de cette manière:

"Hernandez, Michael." Créez un champ calculé appelé C ustomer n AME et utilisez

l'expression de concaténation suivante:

Nom de famille & ", " & Prénom du client

Ajoutez le nouveau champ calculé au diagramme de vue de la liste des appels

clients et supprimez les champs C ust f irst n ame et c ust l ast n ame de la

vue; Vous n'avez plus besoin de ces champs parce que vous utilisez

maintenant le champ calculé C ustomer n AME . (Vous enregistrerez bientôt

également correctement cette expression.)

La figure 12.15 montre à quoi devrait ressembler votre diagramme de vue

révisé une fois ces modifications terminées.

Figure 12.15 Diagramme de vue révisé pour la LISTE D'APPELS CLIENTS.
Comme vous venez de l'apprendre, un champ calculé peut être tout à fait un

atout car vous pouvez l'utiliser pour améliorer les informations fournies par une

vue. Vous avez également appris plus tôt dans ce chapitre que les champs

calculés sont particulièrementcrucial dans les vues agrégées. Une bonne règle

générale à suivre lorsque vous pensez que vous pourriez avoir besoin de

champs calculés est de les utiliser s'ils fournissent des informations pertinentes

et significatives ou s'ils améliorent la manière dont la vue utilise ses données.

Si vous vous en souvenez, vous avez créé une liste de champs calculés plus tôt

dans le processus de conception (reportez-vous au Chapitre 6 , « Analyse de la

base de données actuelle »). Vous pouvez désormais utiliser cette liste comme

source de champs calculés que vous pourriez (ou devriez) utiliser dans vos

vues. Examinez la liste à mesure que vous définissez chaque nouvelle vue et

déterminez si vous pouvez utiliser l'un des champs calculés de la liste. Lorsque

vous en trouvez un que vous pouvez utiliser, créez-le de la même manière que

dans les exemples précédents. (Si vous créez un nouveau champ calculé qui

n'apparaît pas dans votre liste, assurez-vous toutefois de l'ajouter à la liste.

Cela vous aidera à maintenir votre liste de champs calculés à jour et en ordre.)
Imposer des critères pour filtrer les données

Les vues ont une autre caractéristique qui les rend extrêmement utiles : vous

pouvez imposer des critères à un ou plusieurs champs de la vue pour filtrer les

enregistrements qu'elle affiche. Par exemple, supposons que la vue CUSTOMER

CALL LIST inclue le champ C UST S TATE . Même si la vue continue d'afficher

l'ensemble d'enregistrements qu'elle affichait auparavant, vous verrez

également l'état dans lequel vit chaque client. Supposons toutefois que vous

souhaitiez que la vue affiche un ensemble particulier d’enregistrements, tels

que ceux des clients résidant à Washington. Vous pouvez y parvenir en

définissant un critère spécifique dans le champ C UST S TATE qui filtrera les

données afin que la vue affiche uniquement les enregistrements des clients de

Washington.

Note

Dans le travail sur les bases de données, le mot critère fait référence à une

expression qui est testée par rapport à la valeur d'un champ particulier. La vue

inclura un enregistrement donné si la valeur du champ répond au critère.

C'est l'expression que vous utiliserez pour filtrer les enregistrements de la vue

LISTE D'APPELS CLIENT :

État client = « WA »

Désormais, la vue affichera uniquement les clients de Washington. Si vous

souhaitez filtrer davantage les enregistrements pour afficher uniquement les

clients qui vivent dans des villes spécifiques, vous ajoutez un critère tel que

celui-ci :
CustCity In (« Bellevue », « Olympia », « Redmond », « Seattle », « Spokane »,

« Tacoma »)

La vue affichera désormais les clients de Washington qui vivent dans les villes

spécifiées dans l'expression. Vous vous demandez peut-être pourquoi les deux

critères sont nécessaires : le critère du champ C UST C ITY devrait récupérer lui-

même les enregistrements appropriés. Le problème est que de nombreuses

villes portent le nom d’autres villes, de sorte que des villes situées dans deux

ou trois États différents peuvent porter le même nom. Par exemple, il existe un

Portland, dans l'Oregon, et un Portland, dans le Maine, tous deux nommés

d'après Portland, en Angleterre. Le point à retenir est que vous devez faire

preuve de jugement lorsque vous établissez des critères pour une vue. Utilisez

le nombre minimum de critères qui permettront à la vue d'afficher les

enregistrements dont vous avez besoin.

Lorsque vous utilisez un critère dans une vue, vous devez vous assurer que le

champ que vous testez dans le critère est inclus dans la structure de la vue. Si

vous n'incluez pas le champ dans la vue, vous n'avez aucun moyen d'imposer

le critère. C'est un point important à retenir car c'est une exigence lorsque

vous définissez logiquement une vue et lorsque vous implémentez la vue dans

votre SGBDR.

Le seul problème lié à l’application d’un filtre à une vue est qu’il n’existe aucun

moyen de l’indiquer sur un diagramme de vue ; par conséquent, vous devez

l'enregistrer sur une feuille Afficher les spécifications .

Utilisation d'une feuille de spécifications de vue pour enregistrer la vue

Une feuille de spécifications de vue doit accompagner chaque diagramme de

vue que vous créez. Vous noterez les caractéristiques de la vue sur cette

feuille. La feuille Afficher les spécifications contient les éléments suivants :

• Nom : C'est ici que vous indiquez le nom de la vue. Cependant, avant

d'enregistrer le nom, testez-le par rapport aux instructions de création de

noms de table que vous avez apprises au chapitre 7 , « Établir des

structures de table ». Ces directives régissent également la dénomination

des vues, à une exception près : le nom d'une vue peut identifier

implicitement ou explicitement plusieurs sujets. En effet, vous pouvez

définir des vues à partir de deux ou plusieurs tables de base, elles

représentent donc effectivement plus d'un sujet.

• Type : c'est ici que vous indiquez si vous définissez une vue de données,

d'agrégation ou de validation. Assurez-vous de sélectionner le type qui

définit le mieux l’objectif spécifique de la vue.

• Tables de base : c'est ici que vous spécifiez les noms des tables de base de

la vue. Bien que le diagramme de vue montre ces tableaux, ils apparaissent

ici par souci de commodité. Toutefois, la feuille Spécifications de la vue

n'inclut pas les noms de champs, car vous pouvez les enregistrer et les

afficher plus facilement et plus efficacement sur le diagramme de vue.

• Expressions de champs calculés : c'est ici que vous enregistrez les

expressions des champs calculés que vous avez inclus dans la vue. Pendant

que vous enregistrez le nom du champ calculé, testez-le par rapport aux

directives de création de noms de champ que vous avez apprises

au chapitre 7 . Les noms de champs calculés sont régis par ces directives à

deux exceptions près : vous pouvez identifier implicitement ou

explicitement plusieurs caractéristiques dans un nom et vous pouvez utiliser

la forme plurielle du nom. Cependant, il est toujours souhaitable d’utiliser le

singulier du nom autant que possible.

• Filtres : C'est ici que vous enregistrez les critères que la vue utilisera pour

filtrer les enregistrements qu'elle affiche. Vous enregistrerez à la fois le

champ testé et l’expression utilisée pour le tester.

Note
Lorsque vous remplissez les sections Expressions de champs calculés et Filtres

d'une feuille Spécifications de vue, utilisez les expressions avec lesquelles vous

êtes le plus familier. Vous les modifierez si nécessaire lorsque vous

implémenterez la base de données dans un SGBDR.

Remplissez une feuille de spécifications de vue pour chaque vue que vous

créez et joignez la feuille au diagramme de vue approprié. Ces deux éléments

serviront à documenter pleinement la vue. La figure 12.16 montre une feuille

de spécifications de vue complétée pour la vue LISTE D'APPELS CLIENT. (Gardez

à l'esprit que la vue a été mise à jour pour inclure le champ C UST S TATE .)
Figure 12.16 Feuille de spécifications de la vue complétée pour la vue LISTE
D'APPELS CLIENTS.

Révision de la documentation pour chaque vue

Une fois que vous avez terminé la tâche de définition et de documentation de

chaque vue, examinez à nouveau toutes vos vues, en vous assurant que la

qualité des informations fournies par chaque vue en vaut la peine. Lorsque

vous examinez chaque vue, gardez les points suivants à l’esprit.

• Assurez-vous que vous avez correctement défini la vue. Pensez aux

informations que la vue devrait fournir. Établissez-vous le type de vue

correct pour les informations requises ? Avez-vous utilisé les tables de base

appropriées pour définir la vue ? Avez-vous inclus tous les champs

nécessaires dans la structure de la vue ? Seuls les champs nécessaires sont-

ils inclus dans la structure de la vue ?

• Assurez-vous que les champs calculés que vous avez créés conviennent à la

vue. Fournissent-ils des informations pertinentes et significatives ? Est-ce

qu'ils servent à améliorer la manière dont la vue affiche ses données ?

• Assurez-vous que les filtres récupéreront les enregistrements requis. Tout

d’abord, avez-vous besoin d’un filtre pour cette vue ? Si la réponse est

« oui », savez-vous exactement quels enregistrements vous souhaitez que la

vue affiche ? Pensez-vous que le filtre fonctionnera correctement ?

• Surtout, assurez-vous de disposer d'un diagramme de vue et d'une feuille

de spécifications de vue pour chaque vue. Cette documentation vous sera

très utile lorsque vous implémenterez enfin la base de données dans un

SGBDR.

EXEMPLE : DÉTERMINATION ET DÉFINITION DE VUES

Votre travail sur la base de données de Mike touche enfin à sa fin. Vous

rencontrez Mike et son équipe pour déterminer s'il est nécessaire d'établir des

vues pour la base de données. L'ordre du jour que vous avez établi pour la

réunion comprend les étapes suivantes.

1. Passez en revue les notes que vous avez compilées pendant le processus de

conception.

2. Passez en revue chacun des différents échantillons que vous avez

rassemblés au cours des premières étapes du processus de conception.

3. Examinez les sujets représentés par les tableaux de la base de données.

4. Analysez les relations entre les tables.

5. Réviser et étudier les règles métier.

Au fur et à mesure que la réunion progresse, vous identifiez plusieurs vues que

vous devez définir, notamment une vue CLIENTS PRIVILÉGIÉS et une vue

COMPTE DE PRODUITS VENDEURS. La première vue fournira le nom et le

numéro de téléphone de chaque client ayant le statut « Préféré », et la

deuxième vue fournira des informations sur le nombre total de produits

différents fournis par chaque fournisseur.

Vous basez la vue PREFERRED CUSTOMERS sur la table CUSTOMERS et utilisez

les champs C USTOMER ID, CUST

FIRST N AME , CUST L AST NAME , CUST H OME T HONE et S TATUS pour la structure de l

a vue. Avant toiconstruisez la vue, cependant, Mike demande s'il existe un

moyen d'afficher le prénom et le nom ensemble. Vous répondez que cela peut

être fait, vous créez donc un champ calculé appelé C USTOMER N AME qui

concatène les deux champs ensemble ; ce champ remplacera désormais les

champs C UST FIRST N AME et C UST L AST N AME . La figure 12.17 montre le

diagramme de vue pour la vue CLIENTS PRIVILÉGIÉS.

Figure 12.17 Diagramme de vue pour la vue CLIENTS PRIVILÉGIÉS.

Après avoir créé le diagramme de vue, vous notez l'expression que vous

utiliserez pour filtrer les données de la vue :

Statut = « Préféré »

Ensuite, vous remplissez une feuille de spécifications de vue pour la vue

CLIENTS PRIVILÉGIÉS. La figure 12.18 montre les résultats de votre travail.

Figure 12.18 La feuille Spécifications de la vue pour la vue CLIENTS
PRIVILÉGIÉS.

Vous définissez maintenant la vue VENDOR PRODUCT COUNT en utilisant les

tables VENDORS et PRODUCTS comme tables de base de la vue. Vous utilisez

le champ V ENDOR N AME de la table VENDORS pour afficher les noms des

fournisseurs. Ensuite, vous créez un champ calculé appelé P RODUCT C OUNT pour

afficher le nombre total de produits fournis par chaque fournisseur. Voici

l'expression utilisée par le champ pour calculer le total :

Nombre(NomProd)

Créez maintenant un diagramme pour la vue, comme le montre la figure

12.19 .
Figure 12.19 Diagramme de vue pour la vue VENDOR PRODUCT COUNT.

Après avoir déterminé qu'un filtre n'est pas nécessaire pour cette vue, vous

terminez de documenter la vue en remplissant la feuille Spécifications de la

vue illustrée dans la Figure 12.20 .

Figure 12.20 Afficher la feuille de spécifications pour la vue VENDOR
PRODUCT COUNT.

Vous répétez ensuite ce processus pour chaque vue que vous avez identifiée

pour la base de données de Mike.

Résumé

Nous avons commencé ce chapitre par une définition d'une vue et vous avez

appris qu'il s'agit d'une table virtuelle qui ne contient ni ne stocke de

données. Les vues sont utiles pour plusieurs raisons : elles vous permettent de

travailler avec des données provenant de plusieurs tables, elles contribuent à

renforcer l'intégrité des données et à préserver la sécurité ou la confidentialité

des données.

Nous avons ensuite discuté des trois types de vues : données,

agrégation et validation. Vous avez appris que chaque type de vue peut être
basé sur une ou plusieurs tables, d'autres vues ou une combinaison des

deux. Votre SGBDR reconstruira et remplira à nouveau une vue à chaque fois

que vous y accéderez, en utilisant les données les plus récentes des tables de

base de la vue. Comme vous le savez maintenant, il doit y avoir des relations

entre les tables dans une vue multitable (rendant ainsi les informations de la

vue valides et significatives), et les caractéristiques de ces relations sont

transmises à travers la vue. De plus, vous pouvez modifier les données

présentées par de nombreuses vues, et toutes les modifications que vous

apportez aux données sont transmises via la vue aux tables de base. Vous avez

également appris que les vues de validation fonctionnent de la même manière

que les tables de validation et qu'elles présentent des avantages distincts par

rapport aux tables de validation. Par exemple, les vues de validation peuvent

incorporer des données provenant de plusieurs tables.

Le chapitre s'est ensuite poursuivi avec une discussion sur la détermination et

la définition des vues pour la base de données. Ici, vous avez appris plusieurs

points spécifiques à garder à l'esprit lorsque vous travaillez avec les utilisateurs

et la direction pour identifier les exigences d'affichage de l'organisation. Nous

avons ensuite expliqué comment définir une vue et vous avez appris à créer

un diagramme de vue pour documenter la vue. Vous savez maintenant

comment sélectionner des champs dans les tables de base et les affecter à la

vue.

Nous avons ensuite expliqué comment utiliser les champs calculés dans une

vue. Vous avez appris que vous pouviez les utiliser pour fournir des

informations pertinentes et améliorer la façon dont la vue affiche ses

données. Vous avez également appris que les champs calculés sont

particulièrement cruciaux dans les vues globales et que chaqueLe champ

calculé utilise une expression pour dériver la valeur qu'il affiche. Ensuite, vous

avez appris à appliquer un filtre à une vue afin qu'il récupérera et affiche un

ensemble spécifique d'enregistrements. La vue affichera un enregistrement

donné uniquement s'il répond aux critères que vous avez imposés à un ou

plusieurs champs dans la vue. Vous encadrez chaque critère comme une

expression et l'utilisez pour tester la valeur d'un champ particulier.

Le chapitre a clôturé avec une discussion sur la feuille de spécifications de la

vue. Ici, vous avez appris à documenter les caractéristiques de la vue, telles

que son nom et son type. Vous avez également découvert les éléments qui

composent la feuille Spécifications de la vue et comment les utiliser pour

enregistrer les caractéristiques de la vue.

Questions de révision

1. Pourquoi pouvez-vous vous référer à une vue comme une table virtuelle?
2. Énoncez deux raisons pour lesquelles les opinions sont précieuses.

3. Nommez les types de vues que vous pouvez définir lors de la conception de

la structure logique de la base de données.

4. Que fait votre RDMBS chaque fois que vous accédez à une vue de

données (ou à tout type de vue, d'ailleurs) ?

5. Qu'est-ce qui détermine le type de modifications que vous pouvez apporter

aux données d'une vue?

6. Quelle est la seule condition que vous devez remplir pour définir une vue de

données multitable ?

7. Pourquoi une vue de données ne contient-elle pas sa propre clé principale?

8. A quoi sert une vue globale ?

9. Quelles sont les fonctions d'agrégation les plus courantes que vous pouvez

appliquer à un ensemble de données ?

10. Qu'est-ce qu'un champ de regroupement ?

11. Vrai ou faux: vous pouvez modifier les données dans une vue agrégée.

12. Quelle est la différence entre une table de validation et une vue de

validation ?

13. Nommez deux points que vous prendriez en compte lors de l'identification

des exigences en matière de vue.

14. Quand faut-il utiliser les champs calculés ?

15. Comment définir une vue qui affiche uniquement des livres de science-

fiction ?

16. Pourquoi devez-vous remplir une feuille de spécifications de vue pour

chaque vue de la base de données ?

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
12. Vues
13. Examen de l'intégrité des données
Partie III : Autres problèmes de conception de bases de données
2h 30min restant

13

Examen de l'intégrité des données

Une fois l’impossible éliminé, tout ce qui reste, aussi improbable soit-il, doit
être la vérité.

—SHERLOCK H OLMES , LE SIGNE DE QUATRE __

Sujets abordés dans ce chapitre

Pourquoi devriez-vous examiner l'intégrité des données

Examen et affinement de l'intégrité des données

Assemblage de la documentation de la base de données

C'est enfin fait !

Exemple—Récapitulatif

Résumé

Vous êtes maintenant à la dernière étape du processus de conception de la

base de données. Vous avez accompli beaucoup de choses depuis que vous

avez commencé le processus. Jusqu'à présent, vous avez

• Perception des avantages du modèle de base de données relationnelle et de

sa comparaison avec d'autres modèles de bases de données

• Création d'un énoncé de mission pour une nouvelle base de données

• Objectifs de mission définis pour la nouvelle base de données

• Effectuer une analyse complète d'une ancienne base de données

• Identifier les besoins d'information de l'organisation

• Définir toutes les structures de table appropriées

• Attribué une clé primaire à chaque table

• Spécifications de terrain établies pour chaque domaine

• Relations de table établies

• Des règles métier définies et établies

• Définir toutes les vues appropriées

• Intégrité globale des données établie

À toutes fins utiles, votre nouvelle base de données est complète ; néanmoins,

il serait à votre avantage d'effectuer un dernier examen de l'intégrité globale

des données de votre base de données.

Pourquoi devriez-vous examiner l'intégrité des données

Vous vous demandez probablement pourquoi vous devriez revoir la structure

de la base de données une dernière fois, étant donné que vous avez prêté

attention à chaque détail et que vous vous êtes concentré sur l'intégrité des

données tout au long du processus de conception. La réponse est simple : vous

voulez vous assurer que l'intégrité des données que vous avez pris soin

d'établir est absolument aussi solide que possible. Comme vous le savez bien,

une faille dans l’intégrité pourrait entraîner des données incohérentes ou des

informations inexactes. Aussi improbable soit-il, il est possible que vous ayez

oublié quelque chose. La tranquillité d’esprit que vous obtenez en sachant que

vous disposez d’une base de données solidement conçue vaut bien

l’investissement de votre temps et de vos efforts lors de cet examen final.

Note

N'oubliez pas : les déchets rentrent, les déchets sortent !

Examen et affinement de l'intégrité des données

L'examen de l'intégrité des données est une tâche simple si vous adoptez une

approche modulaire ; c'est-à-dire si vous examinez séquentiellement chaque

composant de l'intégrité globale des données : intégrité au niveau de la table,

au niveau du champ et au niveau de la relation.et les règles

commerciales. Vous ne devriez rencontrer ici que très peu de problèmes si vous

avez suivi attentivement la méthode de conception présentée dans ce

livre. Les sections suivantes décrivent brièvement les points que vous devez

garder à l'esprit lors de la révision et contiennent des références aux chapitres

précédents au cas où vous rencontreriez des problèmes.

Intégrité au niveau de la table

Pour vous assurer que vous avez correctement établi l’intégrité au niveau des

tables, examinez chaque table et assurez-vous qu’elle est conforme à tous les

points suivants.

• Aucun champ en double n'existe dans le tableau.

• Aucun champ calculé n'existe dans la table.

• Aucun champ à valeurs multiples n'existe dans la table.

• Aucun champ en plusieurs parties n'existe dans la table.

• Aucun enregistrement en double n'existe dans la table.

• Chaque enregistrement de la table est identifié par une valeur de clé

primaire.

• Chaque clé primaire est conforme aux éléments d'une clé primaire.

Si vous pensez rencontrer des problèmes avec l'un de ces éléments, résolvez-

les à l'aide des techniques et des concepts abordés dans le chapitre 6 ,

« Analyse de la base de données actuelle », le chapitre 7 , « Établissement des

structures de table » et le chapitre 8 , « Clés ».

Intégrité au niveau du terrain

Vous pouvez vous assurer que vous avez correctement établi l’intégrité au

niveau du champ après avoir effectué les opérations suivantes :

• Assurez-vous que chaque champ est conforme aux éléments du champ idéal

• Assurez-vous d'avoir défini un ensemble de spécifications de champ pour

chaque champ.

Vous pouvez résoudre les problèmes d'intégrité au niveau du champ avec les

techniques décrites dans le Chapitre 9 , « Spécifications du champ ».

Intégrité au niveau des relations

Examinez chaque relation de table pour vous assurer que vous avez

correctement établi l’intégrité au niveau de la relation. Vous avez atteint ce

niveau d'intégrité lorsque vous avez accompli ces tâches :

• Bien établir la relation

• Définir les règles de suppression appropriées

• Bien identifié le type de participation pour chaque table

• Établir le degré de participation approprié pour chaque table

Si vous identifiez un problème avec une relation, utilisez les techniques

du chapitre 10 , « Relations entre tables » pour le résoudre.

Règles commerciales

Vous pouvez vous assurer que vos règles commerciales sont solides en vous

assurant que ces tâches sont terminées :

• Vous êtes sûr que chaque règle impose une contrainte significative .

• Vous avez déterminé la catégorie appropriée pour la règle.

• Vous avez correctement défini et établi chaque règle.

• Vous avez modifié les éléments de spécification de champ ou les

caractéristiques de relation de table appropriés.

• Vous avez établi les tables de validation appropriées.

• Vous avez rempli une feuille de spécifications des règles métier pour chaque

règle.

Si vous rencontrez des problèmes avec l'une de vos règles métier, reportez-

vous au Chapitre 11 , « Règles métier », pour connaître les techniques

nécessaires pour les résoudre.

Vues

Bien que les vues ne soient directement liées à aucun composant de l’intégrité

des données, vous devez néanmoins revoir toutes vos structures de

vues. Lorsque vous examinez chaque vue, assurez-vous d'avoir répondu aux

éléments suivants :

• Chaque vue est construite sur les tables de base nécessaires pour fournir les

informations requises.

• Vous avez attribué les champs appropriés à chaque vue.

• Chaque champ calculé fournit des informations pertinentes ou améliore la

manière dont la vue présente ses données.

• Chaque filtre renvoie l'ensemble d'enregistrements approprié.

• Chaque vue possède un diagramme de vue.

• Chaque diagramme de vue est accompagné d'une feuille de spécifications

de vue.

Si vous rencontrez des problèmes avec une vue, résolvez-les en utilisant les

techniques décrites dans le chapitre 12 , « Vues ».

Après avoir effectué cet examen complet, vous pouvez être sûr que la structure

de la base de données est solide, que les données contenues dans la base de

données sont cohérentes et valides et que les informations que vous extrayez

de la base de données seront exactes.

Assemblage de la documentation de la base de données

Tout au long du processus de conception de la base de données, vous avez

généré un certain nombre de listes, de fiches techniques et de diagrammes

utilisés pour enregistrer divers aspectsde la conception de la base de

données. Vous devez maintenant les rassembler dans un référentiel central, de

préférence dans un ensemble de classeurs ou dans un ensemble organisé de

dossiers et de fichiers sur un ordinateur. Le référentiel de conception doit être

composé des ensembles de documents suivants :

• Liste de la table finale

• Fiches de spécifications de terrain

• Liste des champs calculés

• Diagrammes de structure de table

• Diagrammes de relations

• Fiches de spécifications des règles métier

• Voir les diagrammes

• Voir les fiches techniques

Deux ensembles supplémentaires d'éléments que vous pouvez envisager de

conserver avec cette documentation sont les notes que vous avez compilées

pendant le processus de conception et les échantillons que vous avez collectés

pendant la phase d'analyse du processus de conception. Vous pouvez

conserver chacun de ces éléments dans une annexe distincte à la fin de la

documentation.

Tous ces éléments constituent l'ensemble complet de la documentation pour la

conception logique de la base de données. Cette documentation est vitale pour

trois raisons.
1. Il fournit un enregistrement complet de la structure de la base de

données. Vous pouvez retrouver tous les aspects de la structure logique de

la base de données dans la documentation. De plus, vous pouvez répondre

à presque toutes les questions concernant la base de données en vous

référant simplement à la documentation.

2. Il fournit un ensemble complet de spécifications et d'instructions sur la

manière dont la base de données doit être créée pendant le processus de

mise en œuvre. Cette documentation est similaire à celle d'un
architecteplans : il indique comment la base de données doit être

construite. Il identifie également l'intégrité qui doit être établie pour la base

de données. Étant donné que la conception de la base de données n'est pas

orientée vers un SGBDR particulier, les personnes qui mettent en œuvre la

base de données ont toute latitude quant à la manière dont elles

implémentent physiquement la base de données.

3. S'il semble nécessaire de modifier la structure de la base de données au

cours du processus de mise en œuvre, la documentation de conception peut

être utilisée pour déterminer les effets et les conséquences de toute
modification. Toute modification que vous apportez à la structure de la base
de données doit être le résultat d'une décision éclairée. Vous pouvez vous

assurer qu'une modification proposée n'aura pas d'effet négatif sur la

structure de la base de données en référençant d'abord la documentation.

C'est enfin fait !

Maintenant que vous avez terminé l'examen d'intégrité et rassemblé toute la

documentation de la base de données, le processus de conception logique de

la base de données est terminé. Vous pouvez être assuré que vous disposez

d’une base de données correctement conçue et que sa mise en œuvre se

déroulera sans problème. Passons au prochain client et à la prochaine

conception de base de données !

EXEMPLE : RÉCUPÉRATION

C'est votre dernière rencontre avec Mike et son équipe. Votre objectif est de

revoir une dernière fois sa base de données et son intégrité. Même si vous êtes

sûr de ne rencontrer aucun problème, vous souhaitez effectuer un dernier

contrôle qualité de la base de données.

Lors de la réunion, vous examinez chacune des structures de bases de données

pour vous assurer qu'elles sont conformes aux différents éléments qui les

régissent. Vous examinez ensuite chaque composant de l’intégrité globale des

donnéespour vous assurer que vous avez correctement établi l'intégrité au

niveau de la table, du champ et de la relation, ainsi que les règles métier. Enfin,

vous rassemblez toute la documentation que vous avez générée tout au long

du processus de conception. Après avoir rassemblé toute la documentation

dans un ensemble de classeurs, vous remettez les classeurs à Mike et déclarez

que sa base de données est désormais complète. Mike exprime ses

remerciements et sa gratitude pour un travail bien fait et promet que votre

chèque sera envoyé par la poste le 15 du mois. Vous exprimez vos

remerciements à Mike et à son équipe, dites au revoir et partez vers de

nouveaux horizons. Alors que vous partez, Mike regarde dans votre

direction ; Une dernière pensée lui vient à l’esprit :

"Maintenant, si je pouvais juste vous demander d' implémenter ma base de

données pour moi. . . .»

Résumé

Le chapitre s'ouvre sur une liste de vos réalisations depuis le début du

processus de conception de base de données. Il s'est ensuite poursuivi avec

une discussion sur les raisons pour lesquelles vous devriez examiner une

dernière fois l'intégrité globale des données. Cela a été suivi d'une brève

discussion sur les points à garder à l'esprit lorsque vous examinez chaque

composant de l'intégrité globale des données. Nous avons clôturé le chapitre

en discutant de l'importance de la documentation que vous avez rassemblée

tout au long du processus de conception.

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
Partie III : Autres problèmes de conception de bases de données
14. Mauvaise conception : ce qu'il ne faut pas faire
15. Enfreindre ou enfreindre les règles
2h 12min restantes

14

Mauvaise conception : ce qu'il ne faut pas faire

Les erreurs sont toujours initiales.

—C ESARE PAVESE _

Sujets abordés dans ce chapitre

Conception de fichiers plats

Conception de feuille de calcul

Conception de base de données basée sur le logiciel de base de données

Une dernière pensée

Résumé
Vous vous êtes peut-être demandé pourquoi ce chapitre apparaît à la fin du

livre plutôt qu'au début. La raison est simple : vous pouvez comprendre les

dangers présentés par une base de données mal conçue maintenant que vous

avez appris à concevoir correctement une base de données. De plus, vous

serez en mesure de déterminer par vous-même pourquoi une conception

particulière est mauvaise : vous examinerez la conception et serez en mesure

d'identifier immédiatement les problèmes de la structure. Vous possédez

également les connaissances nécessaires pour identifier des solutions possibles

à ces problèmes.

Dans ce chapitre, vous découvrirez les trois approches de conception les plus

courantes qui conduisent à des bases de données mal structurées. Les

discussions sont brèves car elles visent uniquement à illustrer les types de

conception que vous devriez éviter. Il devrait maintenant être évident que la

manière de résoudre une base de données mal conçue consiste à la suivre à

travers le processus de conception complet que vous venez d'apprendre.

Conception « fichier plat »

La conception de fichiers plats (parfois connue sous le nom de conception

« tout mettre dans une seule grande table ») existe depuis de nombreuses

années et est courante dans les bases de données conçues pour être mises en

œuvre dans des systèmes de gestion de bases de données non

relationnelles. Une conception de fichier plat pose de nombreux problèmes,

comme vous pouvez le constater en examinant la structure de la figure 14.1 .

Figure 14.1 Un exemple de structure de fichier plat.

Ce diagramme représente la structure d'une seule table. (Imaginez comment

les autres tables de la base de données sont structurées !) Vous pouvez

facilement voir que cette structure entraînera inévitablement des problèmes de

données redondantes et incohérentes et qu'elle souffre d'un manque

d'intégrité des données. Comme vous l'avez probablement déjà remarqué,

cette structure présente quelques autres problèmes :

• Champs en plusieurs parties : S ALES R EP N AME inclut le prénom et le nom du

commercial, C USTOMER N AME inclut le prénom et le nom du client et

C USTOMER A DDRESS inclut l'adresse postale, la ville, l'état et le code postal du

client.
• Champs calculés : le champ COMMANDER UN MONTAGE contient une valeur qui

est très probablement calculée manuellement, surtout si le client

commande plus de trois articles. Les champs I TEM #E XTENSION sont

également tous susceptibles d'être calculés manuellement. La valeur d'un

champ I TEM #E XTENSION donné est le résultat de la multiplication de la

valeur d'un champ Q UANTITY # associé par la valeur d'un champ P RICE #

associé (par exemple, I TEM 3E XTENSION =Q UANTITY 3xP RIZ 3)

• Champs en double inutiles : chacun des champs relatifs à un élément

particulier est un doublon. Par exemple, les champs I TEM 1, I TEM 2 et I TEM 3

sont des champs en double inutiles.

• Aucune véritable clé primaire : aucun champ ou groupe de champs ne peut

identifier de manière unique un seul enregistrement dans cette table. Le

champ NUMÉRO DE COMMANDE n'est pas une clé primaire dans cette

table ; si un client commande plus de trois articles, vous devrez saisir un

autre enregistrement dans le tableau en utilisant le même numéro de

commande.

• Le tableau représente plusieurs sujets : ce tableau représente trois sujets :

les clients, les commandes et les articles. (Selon votre point de vue, il

représente également les commerciaux.)

Maintenant que vous connaissez les éléments d’une bonne conception de base

de données, vous êtes sûr d’éviter une telle conception.

Conception de feuille de calcul

Une feuille de calcul est certainement un excellent outil si vous l’utilisez

correctement et dans le but pour lequel elle a été conçue. Par exemple, il est

tout à fait adapté aux travaux impliquant des calculs mathématiques

complexes et des analyses statistiques. Cependant, contrairement au mythe

populaire, une feuille de calcul ne constitue pas une bonne base de données

relationnelle. Si votre organisation a besoin de collecter, stocker, conserver et

manipuler différents types de données, utilisez l'outil approprié pour le travail

en concevant et en mettant en œuvre une véritable base de données. Par

exemple, considérons la feuille de calcul de la figure 14.2 .

Figure 14.2 Un exemple de « base de données » typique d’une feuille de

calcul.
Cette feuille de calcul est utilisée pour suivre les gérants de magasin d'une

petite chaîne de magasins de détail. Comme vous pouvez le constater, cette

approche pose également des problèmes :

• Champs en double : chaque champ de cette feuille de calcul est un champ

en double. Si vous prenez les champs à leur valeur nominale, chaque

instance comporte essentiellement trois

champs : NUMÉRO DE MAGASIN , NOM DU MANAGER et NOM DU MANAGER A SSISTA

NT .

• Champs en plusieurs parties : chaque champ contient deux valeurs. Le

premier champ stocke le numéro du magasin et le numéro de téléphone, le

deuxième champ stocke le prénom et le nom du responsable et le troisième

champ stocke le prénom et le nom du directeur adjoint.

• Champs à valeurs multiples : Le champ Gérant adjoint est un champ à valeurs

multiples car plusieurs directeurs adjoints peuvent être affectés à un

magasin particulier.

• Difficile à utiliser : les tâches orientées données qui peuvent être effectuées

facilement dans un programme SGBDR sont fastidieuses et longues à

réaliser dans une feuille de calcul. Par exemple, créer une liste contenant

uniquement le nom de chaque gérant de magasin et son numéro de

téléphone prendrait un certain temps.

Après avoir vu les problèmes associés à une simple « base de données » de

feuille de calcul telle que celle-ci, vous pouvez imaginer les types de problèmes

que vous rencontreriez avec une base de données plus complexe. Si vous

utilisez actuellement une feuille de calcul comme base de données, vous

pouvez améliorer la qualité, la vitesse et la polyvalence de la base de données

si vous la supprimez de la feuille de calcul, la suivez tout au long du processus

de conception de la base de données et l'implémentez dans un SGBDR

approprié.
Gérer la mentalité de la vue feuille de calcul

Lorsque vous commencez à travailler avec une véritable base de données et un

SGBDR, vous devez vous éloigner de l'état d'esprit d'une feuille de calcul. Cela

signifie que vous devrez vous résigner au fait que certaines manières de

visualiser les données ne sont désormais plus disponibles : vous ne pouvez plus

utiliser les mises en page typiques des feuilles de calcul. (En fait, cela vous

offre une excellente opportunité d'explorer de nouvelles voies de travail avec

les données et d'élargir vos compétences.) Par exemple, considérons un

rapport de feuille de calcul typique illustré à la figure 14.3 .

Figure 14.3 Un exemple de rapport de feuille de calcul typique.

Vous ne pouvez pas produire un rapport avec ce type de mise en page à l'aide

d'une base de données. Alors qu'une feuille de calcul stocke les données

exactement telles que vous la voyez sur le rapport, une base de données la

stockerait dans quatre champs distincts dans un tableau. La figure 14.4 montre

un exemple de rapport de base de données que vous pouvez générer pour les

mêmes données. La présentation de la base de données n'est pas la même que

la présentation de la feuille de calcul, mais elle est tout aussi claire.

Figure 14.4 Un exemple de rapport de base de données typique.

Le point à retenir est que vous devrez ajuster la manière dont vous pensez

travailler avec les données de votre base de données. Une vraie base de

données est une ressource partagée; tous les membres de l'entreprise

autorisés à accéder aux données de la base de données peuvent le faire eux-

mêmes, et tout le monde recevra le même ensemble de valeurs de

données. Ceci est différent du tableur, où une « feuille maîtresse » est

conservée sur l'ordinateur portable d'une personne et où tous les autres

tentent en vain de garder leurs copies synchronisées avec la feuille

maîtresse. En fin de compte, il y a bien plus d’avantages à stocker et à utiliser

vos données dans une base de données réelle qu’à essayer d’utiliser une

feuille de calcul de la même manière. Une base de données vous donne

beaucoup plus de contrôle sur l'intégrité des données et la cohérence et la

validité des données. Il offre également un nombre presque illimité de façons

de récupérer les données, vous permettant d'obtenir une grande variété

d'informations.

Conception de base de données basée sur le logiciel de base

de données

Un SGBDR ne fournit pas de base, de procédure ni même de raison pour

concevoir une base de données d'une manière particulière : il fournit

uniquement les outils dont vous avez besoin pour mettre en œuvre une

conception. En revanche, une méthode formelle de conception de base de

données fournit à la fois les principes et la justification nécessaires pour définir

une base de données correctement et efficacement.

De nombreuses personnes tombent involontairement dans le piège de la

conception d'une base de données basée uniquement sur le logiciel RDBMS

qu'ils utiliseront pour son implémentation. Dans de nombreux cas, ils le font

parce qu'ils sont déjà quelque peu familiers et qualifiés avec un SGBDR

particulier ou leur entreprise ou organisation utilise déjà un RDMB particulier. Il

s'agit d'une approche imprudente que vous devez éviter (autant que possible)

pour plusieurs raisons:

• Vous prendrez probablement des décisions de conception en fonction de vos

perceptions de ce que votre SGBDR peut ou ne peut pas faire. Par exemple,
vous pouvez déciderne pas imposer un certain degré de participation pour

une relation donnée parce que vous estimez que le SGBDR ne vous en

donne pas les moyens.

• Vous laisserez par inadvertance le SGBDR dicter la conception de la base de

données, au lieu de piloter la conception strictement en fonction des

besoins en informations de l'organisation. Cela se produit généralement
lorsque vous découvrez que votre SGBDR ne fournit qu'une prise en charge

limitée pour certains aspects de la base de données, tels que les

spécifications de champ et les caractéristiques des relations.

• Votre conception sera limitée par votre connaissance du SGBDR. Par

exemple, vous pouvez décider de ne pas mettre en œuvre les

caractéristiques relationnelles simplement parce que vous ne savez pas

comment le faire.

• Votre conception sera limitée par vos compétences avec votre SGBDR. Votre

niveau de compétence affecte l'efficacité avec laquelle vous pouvez mettre

en œuvre divers aspects de la base de données, tels que les spécifications

de champ et les règles métier.

• L'utilisation de cette approche pour concevoir une base de données entraîne

généralement une conception structurelle incorrecte, une intégrité des

données insuffisante et des problèmes de données incohérentes et
d'informations inexactes. Définir une base de données dans un SGBDR peut
être trompeusement simple. Vous pouvez créer une base de données qui

fonctionne, mais vous aurez très probablement une mauvaise conception

sans le savoir.

• En fin de compte, le SGBDR que vous connaissez et aimez si bien n'est

peut-être pas adapté aux exigences de base de données de votre

organisation .
Vous devez toujours concevoir la structure logique de votre base de données

sans tenir compte d'un quelconque SGBDR. Ce faisant, vous êtes plus

susceptible de concevoir une structure solide, car vous vous concentrerez sur

les besoins en informations de l'organisation. Une fois votre conception

terminée, vous pouvez alors déterminer clairement comment vous devez

implémenter la base de données (application mono-utilisateur, client/serveur,

basée sur le Web, etc.) et quel SGBDR vous devez utiliser pour faciliter la mise

en œuvre.
Une dernière pensée

Au fil des années passées à enseigner la conception de bases de données et à

expliquer aux gens comment utiliser divers logiciels SGBDR, j'ai observé un

phénomène intéressant : les personnes qui connaissent les principes

fondamentaux de la conception de bases de données appropriées comprennent

mieux leur SGBDR et les outils qu'il fournit. que ceux qui connaissent peu, voire

pas du tout, la conception de bases de données. Je pense que cela est dû au

fait que les personnes qui connaissent la conception de bases de données sont

capables de comprendre pourquoi le SGBDR fournit certains outils

et comment elles peuvent (et doivent) les utiliser. Pour cette raison, ainsi que

pour les nombreuses autres raisons présentées dans ce livre, il est tout à fait

avantageux d'apprendre et de comprendre les bonnes techniques de

conception de bases de données. Ce livre ne trace pas la seule route, mais

c'est, je crois, une route droite, sûre et la plus facile à parcourir.

Résumé

Ce chapitre a comparé la conception de bases de données relationnelles avec

des formats de conception plus faibles et moins efficaces. Tout d’abord, nous

avons examiné la conception de fichiers plats. Vous avez appris que cette

approche comporte de nombreux problèmes fatals et que vous devez l’éviter

complètement. Nous avons ensuite examiné la conception d'un tableur et vous

avez constaté à quel point cette approche peut être contrainte. Le chapitre

s'est terminé par une discussion sur la conception d'une base de données à

l'aide d'un logiciel SGBDR. Vous avez appris que ce type de conception dépend

dangereusement de votre familiarité et de votre niveau de compétence avec le

logiciel. Contrairement à une bonne méthode de conception de base de

données, la conception d'une base de données autour d'un SGBDR ne vous

fournit pas de principes ni de justification pour concevoir une structure de base

de données appropriée. En apparence, à court terme, le produit logiciel semble

aussi bon, mais il ne fonctionne tout simplement pas aussi bien à long terme

que la méthode de conception évoquée dans ce livre.

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
14. Mauvaise conception : ce qu'il ne faut pas faire
15. Enfreindre ou enfreindre les règles
16. En conclusion
2h 3min restant

15

Contourner ou enfreindre les règles

La nature n'enfreint jamais ses propres lois.

-LÉONARD DE VINCI _

Sujets abordés dans ce chapitre

Quand pouvez-vous contourner ou enfreindre les règles ?

Documenter vos actions

Résumé
Je préconise toujours de suivre les techniques appropriées de conception de

bases de données. Comme vous l'avez déjà appris, il y a de nombreuses

raisons pour le faire. Mais avant tout, vous devez utiliser une bonne méthode

de conception pour garantir l’intégrité de la base de données. Je ne peux pas

surestimer à quel point cela est important. Vous connaissez maintenant les

conséquences de l'établissement mal de l'intégrité des données, donc suivre

les règles est d'une importance capitale.

Quand pouvez-vous contourner ou enfreindre les règles ?

Il n’existe que deux circonstances spécifiques dans lesquelles il est permis de

contourner ou d’enfreindre les règles de conception appropriée d’une base de

données. À moins que l’un ou l’autre de ces éléments ne constitue un impératif

incontournable, vous devez utiliser des techniques de conception de base de

données appropriées lors de la conception de votre base de données.

Conception d'une base de données analytique

Comme vous l'avez appris au chapitre 1 , « Bases de données relationnelles »,

une base de données analytique stocke et suit les données historiques et

temporelles. Ce type de base de données contient souvent des champs

calculés dans certaines de sesstructures de tableaux. Les expressions utilisées

dans bon nombre de ces domaines sont destinées à enregistrer l’état d’un

ensemble particulier de données à un moment donné ; d'autres champs

stockent les résultats des fonctions d'agrégation.

Vous avez peut-être déjà déduit de la description que ce type de base de

données viole la conception appropriée de la base de données car ses tables

contiennent des champs calculés (reportez-vous au chapitre 7 , « Établir des

structures de table »). Dans ce cas particulier , la violation est acceptable en

raison de la manière dont les données de la base de données sont utilisées. Je

vous recommande d'abord de concevoir correctement la base de données, puis

d'enfreindre les règles seulement après un examen judicieux. Vous devez

prendre la décision délibérée d'enfreindre une règle et comprendre pourquoi

cela est nécessaire dans un cas spécifique.

Note

La conception d'une base de données analytique nécessite une méthodologie

de conception radicalement différente de celle que vous avez apprise dans ce

livre. Si vous déterminez que votre organisation a besoin d'une base de

données analytique, je vous recommande fortement d'acquérir un bon livre sur

le sujet et d'apprendre à concevoir correctement une telle base de données.

Améliorer les performances de traitement

Même à notre époque (2020 au moment d’écrire ces lignes), l’amélioration des

performances de traitement reste la raison la plus courante pour laquelle les

gens se sentent obligés de contourner ou d’enfreindre les règles. Chaque fois

qu'un SGBDR prend ce qui semble être un temps excessif pour traiter des

requêtes multitables ou des rapports complexes, de nombreuses personnes

pensent que la solution au problème consiste à modifier les structures de

tables sous-jacentes. Par exemple, ils vous demanderaient de modifier un

tableau de manière à ce qu'il inclue tous les champs nécessaires à la requête

ou au rapport. Bien que cette modification augmente effectivement la vitesse à

laquelle le SGBDR traite la requête ou le rapport (en particulier dans les

systèmes plus anciens), elle introduit également un certain nombre de

nouveaux problèmes, tels que des champs en double inutiles, des données

redondantes et des problèmes lors de l'édition des données ; en gros, vous

continuez à en échanger unproblème de performances pour un autre. Ce n’est

clairement pas une solution souhaitable car elle viole la bonne conception de la

base de données.

Malheureusement, la vie réelle n'est pas aussi idéale que nous le souhaiterions,

vous constaterez donc parfois que vous devez choisir entre améliorer les

performances de traitement et respecter les principes de conception

appropriés.
Est-ce que ça vaut le coup?

Lorsque vous prenez un moment pour réfléchir sérieusement à ce dilemme,

vous vous rendrez vite compte que la question n'est pas vraiment une question

de performance ; c'est une question d'intégrité des données. Chaque fois que

vous enfreignez les règles pour des raisons de performances (ou pour toute

autre raison, d'ailleurs), vous allez sûrement introduire des problèmes

d'intégrité des données. La question que vous devez alors vous poser est la

suivante : l’augmentation perçue des performances de traitement vaut-elle le

prix d’une intégrité des données réduite (et donc affaiblie) ? Comme vous le

savez, les conséquences de modifications imprudentes de vos structures de

données finiront par se propager, comme des ondulations dans un étang, à

l’ensemble de votre base de données. Voici quelques-uns des problèmes que

vous rencontrerez :

• Données incohérentes : cela résulte de l'introduction de champs en double

inutiles dans une table. Il sera de votre responsabilité (ou celle de votre

programme d'application) de vous assurer que les données de ces champs

sont synchronisées ; si vous modifiez la valeur dans un champ en double

particulier, vous devrez vous assurer que la même modification est apportée

aux champs en double restants.

• Données redondantes : les données redondantes résultent également de

l'introduction de champs en double inutiles dans une table. Lorsque vous

modifiez une valeur particulière dans un champ contenant des données

redondantes, vous devez vous assurer d'effectuer la même modification

pour chaque instance de cette valeur.

• Intégrité des données altérée : le contournement ou la violation des règles

viole souvent un ou plusieurs composants de l'intégrité globale des

données, tels que l'intégrité au niveau des tables et l'intégrité au niveau des

relations. Il sera de votre responsabilité (ou celle de votre programme de

candidature) de compenserpour le manque d’intégrité – quelle que soit la

manière dont il se manifeste – du mieux que vous pouvez.

• Informations inexactes : vous ne pouvez pas vous attendre à ce que la base

de données fournisse des informations exactes si elle présente l'un des

problèmes susmentionnés.
Améliorer d’abord les performances par d’autres moyens

Si vous pensez toujours vouloir poursuivre cette action pour améliorer les

performances de traitement, ne le faites qu'en dernier recours. Cependant,

avant de prendre ces mesures, essayez d’abord d’améliorer les performances

par d’autres moyens. Considérez ces alternatives :

• Améliorer ou mettre à niveau le matériel informatique. Le matériel a

vraiment parcouru un long chemin au cours des 25 dernières années, c'est

donc toujours le moyen le plus simple d'augmenter les performances de

traitement. Des éléments tels qu'un processeur plus rapide, plus de

mémoire, le passage à des périphériques à semi-conducteurs, l'obtention

d'une imprimante qui répond mieux à vos besoins d'impression et la mise à

niveau du réseau contribueront tous à réduire considérablement le temps

nécessaire au SGBDR pour traiter une requête ou un rapport complexe. .

• Affinez le logiciel du système d’exploitation. Assurez-vous que le système

d'exploitation de l'ordinateur est optimisé pour les performances de

pointe. Ceci est particulièrement important pour les ordinateurs en réseau

et le matériel de serveur. Vous pouvez améliorer considérablement les

performances du traitement général en travaillant avec les paramètres

d'options de configuration. Les types de modifications que vous apportez au

système d'exploitation en général dépendra de votre système

d'exploitation, vous devrez donc vous référer à votre documentation pour

déterminer les types de modifications que vous pouvez apporter.

• Examinez la structure de la base de données. Assurez-vous absolument que

la base de données est correctement conçue. Cela fait toute une

différence. Des bases de données mal conçues contribuent en réalité à de

mauvaises performances de traitement.

• Vérifiez la mise en œuvre de la base de données. Examinez comment la

base de données est actuellement mise en œuvre dans les SGBDR. Assurez-

vous que vous avez pleinement profité des capacités du SGBDR et que vous

avez défini la base de données aussi efficacement et complètement que

possible.

• Passez en revue le programme d'application utilisé pour travailler avec la

base de données. Voici un autre domaine que vous devriez examiner de très
près. Le programme de candidature est-il bien rédigé ? Utilise-t-il au mieux

les outils fournis par le SGBDR ? Les composants de l'application sont-ils

bien définis ? Dans certains cas, un rapport peut imprimer plus lentement

car il est mal conçu - il peut y avoir des moyens plus efficaces de concevoir

et de générer le même rapport. Les requêtes peuvent s'exécuter lentement

car elles sont mal définies. Assurez-vous que chaque requête est définie

correctement et de la manière la plus efficace possible.

Si vous pensez que vous devez vous éloigner des techniques appropriées de

conception de la base de données, examinez attentivement votre

situation. Comme je l'ai mentionné plus tôt, il est acceptable de suspendre les

règles si vous concevez une base de données analytique. Mais je vous

recommande tout de même fortement de concevoir votre base de données

correctement et minutieusement et d'assouplir les règles uniquement pour des

raisons très spécifiques.

Documenter vos actions

Si vous avez épuisé toutes les autres options et que vous arrivez toujours à la

conclusion que vous devez plier ou enfreindre les règles, vous devez

documenter chaque règle que vous enfreignez et chaque action que vous
prenez! Documenter vos modifications est important car cela vous obligera à
réfléchir aux conséquences de ce que vous êtes sur le point de faire et fournit

un moyen d'enregistrer les modifications que vous apportez à la structure de la

base de données. Si vous décidez plus tard que les modifications n'ont pas

fourni d'avantages significatifs, vous pouvez utiliser la documentation comme

guide pour inverser les modifications que vous avez initialement apportées.

Ce sont les éléments que vous devez enregistrer.

• La raison pour laquelle vous enfreignez les règles : L'augmentation des

performances de traitement et la réduction du temps nécessaire à

l'impression de rapports complexes sont deux des raisons les plus courantes

pour lesquelles vous enfreignez les règles. Quelle que soit votre raison,

assurez-vous de l’énoncer de manière complète et claire.

• Le principe de conception que vous violez: enregistrer comment vous avez

modifié la conception de la base de données vous donnera les moyens

d'inverser ces modifications ultérieurement si vous déterminez que les

performances ne s'amélioraient pas de manière significative. Vous pourriez

indiquer que vous modifiez la structure d'une table, par exemple.

• L'aspect de la base de données que vous modifiez : indiquez le champ, la

table, la relation ou la vue que vous allez modifier. Encore une fois, ces

informations vous seront précieuses si vous décidez d’annuler les

modifications.

• Les modifications spécifiques que vous apportez : après avoir déterminé

quel élément vous devez modifier, enregistrez les modifications exactes que

vous apportez à cet élément. Par exemple, si vous devez modifier une

relation, notez les modifications exactes que vous apportez à ses

caractéristiques.

• Les effets attendus sur la base de données et le programme

d'application : Toute modification que vous apportez à la base de données

affectera tous les programmes d'application de l'utilisateur final qui

l'accompagnent. Par exemple, la modification de la structure d'un tableau

particulier peut affecter l'intégrité des données, les structures de

visualisation, les formulaires de saisie de données et les rapports construits

sur le tableau (partiellement ou totalement) et le code de programmation

qui fait référence au tableau. Vous devez vous assurer de lister tous les

effets.

Ajoutez ce document à la documentation que vous avez compilée pour la base

de données. Même si vous inversez les changements plus tard, ce dossier

pourrait vous empêcher de céder à une future impulsion pour tenter les mêmes

types de changements.
Résumé

Le chapitre s'ouvre sur l'examen des deux circonstances dans lesquelles vous

pourriez vous sentir obligé de vous écarter des techniques appropriées de

conception de bases de données. Vous avez appris que le fait de enfreindre les

règles est acceptable si vous concevez une base de données analytique; sinon,

vous devez d’abord concevoir correctement la base de données, puis prendre

des décisions délibérées pour enfreindre ou contourner des règles

spécifiques. Vous avez ensuite appris que la raison la plus courante de quitter

les techniques de conception appropriées est d'améliorer les performances de

traitement. Bien que ce ne soit pas une raison satisfaisante de enfreindre les

règles, il y a des moments où les circonstances dictent que vous devez

considérer de tels changements.

Nous avons ensuite poursuivi en discutant des mesures alternatives que vous

pouvez prendre pour améliorer les performances de traitement, telles que

l'amélioration ou la mise à niveau du matériel et la révision de la mise en

œuvre de la base de données. Vous avez appris que vous devriez faire tout ce

que vous pouvez d'abord améliorer les performances et vous éloigner des

techniques de conception appropriées uniquement en dernier recours. Le

chapitre a ensuite clôturé avec une liste d'éléments que vous devez enregistrer

tsi vous devez enfreindre les règles.

a
b
rl
dqP
ouaee
serc
uahd
em
e
èrs
tc
rhm
ea
st
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
15. Enfreindre ou enfreindre les règles
16. En conclusion
Partie IV : Annexes
2h 3min restant

16

En conclusion

Je ne suis pas un enseignant : seulement un compagnon de voyage à qui vous

avez demandé le chemin. J'ai pointé devant moi, devant moi et devant vous.

-GEORGE BERNARD SHAW ___

J'ai toujours pensé qu'il ne fallait pas être un génie pour concevoir

correctement une base de données. Cela devrait être une tâche relativement

simple que toute personne possédant une bonne dose de bon sens peut

accomplir. Tant que vous suivez une bonne méthode de conception de base de

données, vous devriez être capable de concevoir une structure de base de

données solide et fiable.

Vous possédez désormais les connaissances et les compétences nécessaires

pour concevoir une base de données relationnelle. Vous savez définir les

structures nécessaires, établir des relations entre les tables et mettre en œuvre

différents niveaux d'intégrité des données. Si vous rencontrez des structures

mal ou mal conçues, vous savez désormais comment les améliorer.

L'apprentissage de la conception de bases de données est un processus

continu. Je devrais le savoir. J'y travaille depuis très longtemps maintenant.

Vous pouvez en apprendre suffisamment pour concevoir les types de bases de

données dont vous avez besoin, vous pouvez en faire un métier ou même en

faire une étude permanente. Quelle que soit votre approche, vous serez

confronté à un fait incontournable : plus vous en apprenez, plus vous réalisez

que vous ne savez pas tout. Mais ne vous découragez pas ; cela est vrai pour
n'importe quelle matière majeure que vous essayez d'apprendre, comme la

musique, le théâtre, l'art, la philosophie ou la science des fusées !

J'espère sincèrement que vous avez pris autant de plaisir à lire l'édition du 25 e

anniversaire de ce livre que j'ai eu à l'écrire. Je sais que la plupart des

livres techniques de cette nature peuvent être un peu secs, alors j'ai essayé

d'injecter un peude l'humour de temps en temps, notamment dans les

dialogues d'entretien et de réunion. Ceux d'entre vous qui pensaient que les

conversations étaient relativement réalistes sont assez perspicaces : elles

étaient très vaguement basées sur un certain nombre d'entretiens et de

conversations que j'ai eus avec mes clients au fil des ans.

En guise de dernier conseil, permettez-moi de vous laisser avec ces sept mots :

Apprenez toujours. Prendre des risques. Ne jamais dire jamais.

N'ayez pas peur, intimidé ou réticent à apprendre quelque chose de

nouveau. L'apprentissage ouvre la porte à de nouvelles choses, à de nouvelles

idées, à des concepts différents et à de nouvelles perceptions. Et n'ayez pas

peur ou n'hésitez pas à prendre des risques dans la vie. C'est un excellent

moyen de changer de cap dans votre vie et peut vous aider à mener une vie

plus épanouie. Comme le dit le vieil adage : « Rien ne risque rien ne gagne

». Enfin, apprenez à ne pas dire « Jamais » : « Je ne ferai jamais ça », « Cela

n’arrivera jamais », « Je n’y vivrai jamais ». Quand vous dites « Jamais »,

l’Univers a une drôle de façon de dire « Pas tellement. . . .» J'ai passé toute ma

vie à apprendre et à prendre des risques. C'est comme ça que j'ai pu faire tant

de choses dans ma vie. Et j'ai enfin vraiment compris comment ne pas dire «

Jamais » dans ma vie.

Je peux certainement vous dire, d'après ma propre expérience personnelle, que

tout ce que je viens de dire est absolument vrai.

Un voyage commence par un seul pas. Vous avez fait le premier pas dans

l'apprentissage de la conception d'une base de données en lisant ce livre. Vous

allez maintenant poursuivre votre voyage en découvrant d’autres facettes de la

gestion de bases de données.

Mon livre se termine ici, mais votre voyage ne fait que commencer. . . .
t
a
bdqP
r
louae
eserc
ahu
dem
eèr
stc
rh
m
e
as
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
Partie IV : Annexes
A : Réponses aux questions de révision
B: Diagramme du processus de conception de la base de données
1h 37min restant

UN

Réponses aux questions de révision

Chapitre 1

1. Les deux principaux types de bases de données utilisées aujourd’hui

sont opérationnelles et analytiques.

2. Une base de données analytique stocke des données statiques .

3. Vrai. Une base de données opérationnelle est utilisée principalement dans

les scénarios OLTP.

4. Le modèle relationnel est basé sur deux branches des mathématiques : la

théorie des ensembles et la logique des prédicats du premier ordre.

5. Une base de données relationnelle stocke les données dans les relations, ce

que l'utilisateur perçoit comme des tables.

6. Voici les types de relations dans une base de données relationnelle :

1. Un par un

2. Un à plusieurs

3. Plusieurs à plusieurs

7. Vous récupérez des données dans une base de données relationnelle

principalement en utilisant SQL, un langage de requête structuré.

8. Ce sont les avantages d'une base de données relationnelle:

1. Intégrité multiniveau intégrée

2. Les données logiques et physiques indépendance des applications de base

de données

3. Cohérence et précision des données garanties

4. Récupération des données facile

9. Un système de gestion de base de données relationnelle, ou SGBDR, est un

logiciel que vous utilisez pour créer, maintenir, modifier et manipuler une base

de données relationnelle.

10. Faux. Les appareils mobiles peuvent avoir des gigaoctets ou des téraoctets

de stockage.

11. Les éditeurs de logiciels ont eu du mal à mettre en œuvre initialement la

base de données relationnelle car la vitesse de traitement, la mémoire et le

stockage étaient tout simplement insuffisants pour fournir aux éditeurs de

logiciels de bases de données une plate-forme sur laquelle construire une

implémentation complète.

Chapitre 2

1. Le meilleur moment pour utiliser les outils de conception du programme du

SGBDR est après avoir conçu la structure logique de la base de données.

2. Vrai. La conception est cruciale pour la cohérence, l’intégrité et l’exactitude

des données.

3. Le résultat le plus préjudiciable d’une mauvaise conception de base de

données est l’inexactitude des informations.

4. Le fait que le modèle de base de données relationnelle soit basé sur la

théorie des ensembles et la logique des prédicats de premier ordre rend la

base de données relationnelle structurellement solide et capable de garantir

des informations précises.

5. Voici les avantages de l’apprentissage d’une méthodologie de conception :

1. Il vous donne les compétences dont vous avez besoin pour concevoir une

structure de base de données solide.

2. Il vous fournit un ensemble organisé de techniques qui vous guideront pas à

pas dans le processus de conception.

3. Cela vous aide à minimiser vos faux pas et vos réitérations de conception.

4. Cela facilite le processus de conception et réduit le temps que vous

consacrez à la conception de la base de données.

5. Il vous aidera à comprendre et à utiliser votre logiciel SGBDR de plus en plus

et efficacement.

6. C'est vrai. Comprendre la conception de bases de données vous aidera à

utiliser votre programme SGBDR de manière plus efficace et efficiente.

7. Voici les objectifs d’une bonne conception :

1. La base de données prend en charge requise et récupération des

informations ad hoc.

2. Les tables sont construites correctement et efficacement.

3. L'intégrité des données est imposée au niveau du champ, de la table et des

relations.

4. La base de données prend en charge les règles métier pertinentes pour

l'organisation.

5. La base de données se prête à une croissance future.

8. L'intégrité des données permet de garantir que les structures de données et

leurs valeurs sont valides et exactes à tout moment.

9. Ce sont les avantages de l'application de bonnes techniques de conception:

1. La structure de la base de données est facile à modifier et à maintenir.

2. Les données sont faciles à modifier.

3. Les informations sont faciles à récupérer.

4. Les applications des utilisateurs finaux sont faciles à développer et à créer.

10. Faux. Vous ne pouvez pas prendre de raccourcis dans certains processus de

conception tout en parvenant à une bonne conception solide.

chapitre 3

1. La terminologie est importante pour les raisons suivantes :

1. Il est utilisé pour exprimer et définir les idées et concepts particuliers du

modèle de base de données relationnelle.

2. Il est utilisé pour exprimer et définir le processus de conception de la base

de données lui-même.

3. Il est utilisé partout où une base de données relationnelle ou le RDBM est

discutée.

2. Les quatre catégories de termes sont liés aux valeurs , liés à la structure ,

liés aux relations et liés à l'intégrité .

3. Les valeurs que vous stockez dans la base de données sont des

données. Les informations sont des données que vous traitez de manière à les
rendre significatives et utiles lorsque vous les utilisez ou les consultez.

4. Null représente une valeur manquante ou inconnue.

5. L'inconvénient majeur de NULL est qu'il a un effet négatif sur les opérations

mathématiques.

6. Les tables sont les principales structures de la base de données.

7. Les trois types de tableaux sont des tables de données , des tables de

liaison et des tables de validation .

8. Une vue est une table virtuelle composée de champs provenant d'une ou

plusieurs tables de base de la base de données.

9. Une clé est une structure logique que vous utilisez pour identifier les

enregistrements dans un tableau, et un index est une structure physique que

vous utilisez pour optimiser le traitement des données.

10. Les trois types de relations qui peuvent exister entre une paire de tables

sont un à un, un à plusieurs et plusieurs à plusieurs.

11. Vous pouvez caractériser chaque relation de trois manières : par le type de

relation qui existe entre les tables, la manière dont chaque table participe et le

degré de participation de chaque table.

12. Une spécification de champ représente tous les éléments d'un champ.

13. Une spécification de terrain intègre les trois types d'éléments

suivants : généraux, physiques et logiques.

14. L'intégrité des données fait référence à la validité, à la cohérence et à la

précision des données dans une base de données.

15. Les quatre types d'intégrité des données sont les règles de niveau champ ,

de table , de relation et de gestion .

Chapitre 4

1. Il est important de compléter soigneusement le processus de conception car

il vous aide à assurer une structure sonore et une intégrité des données.

2. Vrai. Le niveau d’intégrité structurelle est directement proportionnel à la

façon dont vous suivez minutieusement le processus de conception.

3. L' énoncé de mission identifie le but de votre base de données.

4. Les objectifs de mission sont des déclarations qui représentent les tâches

générales que vos utilisateurs peuvent effectuer par rapport aux données de la

base de données.

5. La liste des champs et des calculs que vous compilez au cours de la

deuxième phase du processus de conception constitue les exigences

fondamentales en matière de données de votre organisation.

6. Vous déterminez les différents sujets que les tableaux représenteront à partir

des objectifs de mission que vous avez rédigés au cours de la première phase

du processus de conception et des exigences en matière de données que vous

avez recueillies au cours de la deuxième phase.

7. FAUX. Vous établissez les spécifications de champ pour chaque champ de la

base de données au cours de la troisième phase du processus de conception de

la base de données.
8. Vous établissez une connexion logique entre les tables en relation soit avec

des clés primaires et des clés étrangères, soit avec une table de liaison.

9. La manière dont votre organisation visualise et utilise ses données

déterminera un ensemble de limitations et d'exigences que vous devez

intégrer à la base de données.

10. Vous pouvez définir et implémenter des tables de validation si nécessaire

pour prendre en charge certaines règles métier.

11. Vous identifiez les types de vues que vous devez créer dans la base de

données en interviewant les utilisateurs et en gestion et en déterminant

comment ils fonctionnent avec leurs données respectives.

12. Vous pouvez implémenter la structure de la base de données logique dans

un programme SGBDR après avoir terminé l'ensemble du processus de

conception de la base de données.

Chapitre 5

1. Les entretiens sont importants car ils constituent un lien de communication

précieux entre vous (le développeur) et les personnes pour lesquelles vous

concevez la base de données. Ils contribuent à garantir le succès de vos efforts

de conception et fournissent des informations critiques qui peuvent affecter la

conception de la structure de la base de données.

2. Le problème qui se pose lorsque vous effectuez une entrevue avec un grand

nombre de personnes est que le niveau d'intimidation de certains participants

augmentera en proportion directe avec le nombre de participants participant à

l'entretien dans son ensemble.

3. La principale raison de mener des entretiens distincts avec les utilisateurs et

la direction est que chaque groupe a un autrePerspective sur l'organisation

dans son ensemble et sur la façon dont l'organisation utilise quotidiennement

ses données.

4. Faux. Vous utiliserez généralement des questions ouvertes dans vos

entretiens.

5. Vous devriez essayer d'obtenir des réponses complètes et descriptives de la

part des participants à l'entretien.

6. La ligne directrice la plus importante pour chaque entretien que vous menez

est de toujours garder le contrôle de l’entretien.

7. Un énoncé de mission déclare l'objectif spécifique de la base de données en

termes généraux.

8. Un énoncé de mission bien écrit a les caractéristiques suivantes:

1. C’est sans ambiguïté.

2. C’est succinct et pertinent.

3. Ce sont exempts de phrases ou de phrases qui décrivent explicitement des

tâches spécifiques.

9. Faux. Vous devez en savoir plus sur l'organisation pour composer un énoncé

de mission.

10. Votre énoncé de mission est complet lorsque vous disposez d'une phrase

qui décrit l'objectif spécifique de la base de données et qui est comprise et

acceptée par toutes les personnes concernées.

11. Un objectif de mission est une déclaration qui représente une seule tâche

générale prise en charge par les données maintenues dans la base de données.
12. Un objectif de mission bien écrit a les caractéristiques suivantes:

1. Il s'agit d'une phrase déclarative qui définit clairement une tâche générale

et est exempte de détails inutiles.

2. Il s'exprime en termes généraux.

3. C’est succinct et pertinent.

4. C’est sans ambiguïté.

13. C'est vrai. Vous devez interroger les utilisateurs et la direction pour vous

aider à définir les objectifs de la mission.

14. Le travail quotidien du personnel concerne les objectifs de la mission dans

la mesure où bon nombre des tâches qu'ils effectuent deviendront des objectifs

de la mission.

15. Faux. Un objectif de mission ne peut pas décrire plus d'une tâche.

16. Un objectif de mission peut être dérivé d'une réponse explicitement ou

implicitement.

17. Un objectif de mission est complet lorsqu'il est à la fois correctement défini

et bien défini, et quand il est logique pour vous et pour ceux pour qui vous

concevez la base de données.

Chapitre 6

1. Les objectifs de l'analyse de la base de données actuelle sont de déterminer

les éléments suivants :

1. Quels types de données que l'organisation utilise

2. Comment l'organisation utilise ses données

3. Comment l'organisation gère et maintient ses données

2. Faux. Vous ne devez pas adopter la structure de la base de données actuelle

comme base de la nouvelle structure.

3. Une base de données existante est une base de données qui existe et est

utilisée depuis cinq ans ou plus.

4. Le processus d'analyse intègre ces trois étapes:

1. Examiner la façon dont les données sont collectées

2. Examiner la manière dont les informations sont présentées

3. Mener des entretiens avec des utilisateurs et la direction

5. Les types de logiciels informatiques que vous devez examiner lors de

l'analyse comprennent les traitements de texte, les feuilles de calcul, les bases

de données et les pages Web.

6. Vous devez mener des entretiens après avoir collecté des échantillons de

collecte de données et de présentation d'informations pour les raisons

suivantes :

1. Ils fournissent des détails sur les échantillons que vous avez assemblés lors

des examens précédents.

2. Ils renseignent sur la manière dont l’organisation utilise ses données.

3. Ils jouent un rôle déterminant dans la définition des structures préliminaires

des champs et des tables.

4. Ils aident à définir les futurs besoins d’information.

7. Vous utilisez des questions ouvertes pour vous concentrer sur des sujets

spécifiques et des questions fermées pour vous concentrer sur des détails

spécifiques d'un sujet donné.

8. La technique d'identification du sujet vous permet d'identifier les sujets dans

la réponse d'un participant à une question donnée.

9. Vous identifiez des attributs spécifiques pour un sujet particulier en utilisant

la technique d'identification des caractéristiques.

10. Faux. Vous devez interroger les utilisateurs et la gestion séparément.

11. Les trois types de base d'informations que vous devez identifier

sont actuels, supplémentaires et futurs.

12. La liste préliminaire des champs représente les exigences fondamentales

en matière de données de l'organisation et constitue l'ensemble principal des

champs que vous devez définir dans la base de données.

13. Chaque élément de la liste de champs préliminaire doit avoir un nom

unique pour s'assurer que la caractéristique n'apparaît qu'une seule fois sur la

liste.

14. Une liste de valeurs spécifie la plage acceptable de valeurs pour une

caractéristique particulière et applique souvent une règle commerciale donnée.

15. Un champ calculé stocke le résultat d'une concaténation de chaînes ou

d'une expression mathématique comme valeur. Vous devez supprimer les

champs calculés de la liste des champs préliminaires et les placer sur une liste

de champs calculée dédiée.

Chapitre 7

1. Vous identifiez et établissez des tables pour une nouvelle base de données à

l'aide de la liste de tables préliminaire.

2. Vous utilisez la liste de champs préliminaire pour vous aider à définir des

tables pour la base de données, car les champs de la liste peuvent impliquer

des sujets que la base de données doit suivre.

3. Lorsqu'un élément sur la liste des sujets et un élément nommé différemment

sur la liste de table préliminaire représentent tous deux le même sujet, vous

sélectionnez le nom qui représente le mieux le sujet et l'utilisez comme seul

identifiant pour ce sujet.

4. La liste des tableaux finales fournit le nom, le type et la description de

chaque table dans la base de données.

5. Ce sont les directives pour créer des noms de table:

1. Créez un nom unique et descriptif qui ait du sens pour l'ensemble de

l'organisation.

2. Créez un nom qui identifie avec précision, clarté et sans ambiguïté le sujet

du tableau.

3. Utilisez le nombre minimum de mots nécessaire pour transmettre le sujet du

tableau.

4. N'utilisez pas de mots qui véhiculent des caractéristiques physiques.

5. N'utilisez pas d'acronymes et d'abréviations.

6. N'utilisez pas de noms propres ou d'autres mots qui restreindraient

indûment les données pouvant être saisies dans le tableau.

7. N'utilisez pas de nom qui identifie implicitement ou explicitement plus d'un

sujet.

8. Utilisez la forme plurielle du nom.

6. Ce sont les directives pour composer des descriptions de table:

1. Incluez une déclaration qui définit avec précision le tableau.

2. Incluez une déclaration expliquant pourquoi ce tableau est important pour

l’organisation.

3. Rédigez une description claire et succincte.

4. N'incluez pas d'informations spécifiques à l'implémentation dans la

description de votre table, telles que la manière et l'endroit où la table est

utilisée.

5. Ne faites pas dépendre la description d'une table de la description d'une

autre table.

6. N'utilisez pas d'exemples dans une description de tableau.

7. Vous attribuez des champs à un tableau sur la liste des tableaux finaux en

déterminant les champs qui représentent le mieux les caractéristiques du sujet

du tableau.

8. Ce sont les directives pour créer des noms de champ:

1. Créez un nom unique et descriptif qui ait du sens pour l'ensemble de

l'organisation.

2. Créez un nom qui identifie avec précision, clarté et sans ambiguïté la

caractéristique qu'un champ représente.

3. Utilisez le nombre minimum de mots nécessaire pour transmettre la

signification de la caractéristique représentée par le champ.

4. N'utilisez pas les acronymes et utilisez judicieusement les abréviations.

5. N'utilisez pas de mots qui pourraient confondre la signification du nom du

champ.

6. N'utilisez pas de noms qui identifient implicitement ou explicitement plus

d'une caractéristique.

7. Utilisez la forme singulière du nom.

9. Les champs mal conçus peuvent entraîner des problèmes de données en

double et de données redondantes.

10. Vous pouvez résoudre les anomalies du champ en vous assurant que le

champ est conforme aux éléments du champ idéal.

11. Ce sont les éléments du champ idéal:

1. Il représente une caractéristique distincte du sujet du tableau.

2. Il ne contient qu'une seule valeur.

3. Il ne peut pas être déconstruit en composants plus petits.

4. Il ne contient pas de valeur calculée ou concaténée.

5. Il est unique dans toute la structure de la base de données.

6. Il conserve la majorité de ses caractéristiques lorsqu'il apparaît dans plus

d'un tableau.

12. Les données redondantes sont acceptables lorsqu'elle est le résultat de la

résolution d'un champ multivaleur ou d'un champ en double inutile, mais

uniquement lorsque vous êtes dans les étapes initiales de la conception de

tables.

13. En termes généraux, ce sont les trois étapes que vous suivez pour résoudre

un champ multivaleur:

1. Supprimez le champ de la table et utilisez-le comme base pour une nouvelle

table.

2. Utilisez un champ (ou un ensemble de champs) de la table d'origine pour

associer la table d'origine à la nouvelle table.

3. Attribuez un nom, un type et une description appropriés à la nouvelle table

et ajoutez-la à la liste des tables finales.

14. La seule instance dans laquelle l'utilisation d'un champ en double dans un

tableau est nécessaire est lorsque le champ sert à établir une relation entre

deux tables.

15. Vous pouvez affiner les structures des tableaux en vous assurant que

chaque tableau est conforme aux éléments du tableau idéal.

16. Voici les éléments de la table idéale :

1. Il représente un sujet unique, qui peut être un objet ou un événement.

2. Il possède une clé primaire.

3. Il ne contient pas de champs en plusieurs parties ou à valeurs multiples.

4. Il ne contient pas de champs calculés.

5. Il ne contient pas de champs en double inutiles.

6. Il ne contient qu’un minimum absolu de données redondantes.

17. Un tableau de sous-ensemble est un tableau qui représente un sujet

subordonné d'une table de données particulière.

Chapitre 8

1. Les clés sont importantes pour les raisons suivantes :

1. Ils s'assurent que chaque enregistrement dans un tableau est correctement

identifié.

2. Ils aident à établir et à faire respecter divers types d’intégrité.

3. Ils servent à établir des relations entre les tables.

2. Les quatre principaux types de clés sont candidates, primaires,

étrangères et non.

3. Le but d'une clé candidate est d'identifier de manière unique une seule

instance du sujet du tableau.

4. Voici les éléments d’une clé de candidat :

1. Il ne peut pas s'agir d'un champ en plusieurs parties.

2. Il doit contenir des valeurs uniques.

3. Il ne peut pas contenir Null.

4. Sa valeur n'est pas facultative en tout ou en partie.

5. Il comprend un nombre minimum de champs nécessaires pour définir

l'unicité.
6. Ses valeurs doivent identifier de manière unique et exclusive chaque

enregistrement de la table.

7. Sa valeur doit identifier exclusivement la valeur de chaque champ au sein

d'un enregistrement donné.

8. Sa valeur ne peut être modifiée que dans des cas rares ou extrêmes.

5. Vrai. Une clé candidate peut être composée de plusieurs champs.

6. Oui, une table peut avoir plusieurs clés candidates.

7. Un champ que vous créez dans le seul but de servir de clé de candidat est

connu comme une clé de candidat artificiel. Vous créez ce type de clé lorsqu’il

n’y a pas de clés candidates « naturelles » dans une table.

8. La clé primaire est la clé la plus importante que vous attribuez à une table.

9. La clé principale est importante pour les raisons suivantes:

1. Un champ de clé primaire identifie exclusivement la table dans la structure

de la base de données et permet d'établir des relations avec d'autres tables.

2. Une valeur de clé primaire identifie de manière unique un enregistrement

donné dans une table et représente exclusivement cet enregistrement dans

l'ensemble de la base de données. Cela permet également de se prémunir

contre les enregistrements en double.

10. Vous établissez une clé primaire en examinant le pool de clés candidats

disponibles de la table, puis en en sélectionnant une comme clé principale.

11. Voici les éléments d'une clé primaire :

1. Il ne peut pas s'agir d'un champ en plusieurs parties.

2. Il doit contenir des valeurs uniques.

3. Il ne peut pas contenir Null.

4. Sa valeur n'est pas facultative en tout ou en partie.

5. Il comprend un nombre minimum de champs nécessaires pour définir

l'unicité.

6. Ses valeurs doivent identifier de manière unique et exclusive chaque

enregistrement de la table.

7. Sa valeur doit identifier exclusivement la valeur de chaque champ au sein

d'un enregistrement donné.

8. Sa valeur ne peut être modifiée que dans des cas rares ou extrêmes.

12. Avant de finaliser votre sélection d'une clé primaire, vous devez vous

assurer absolument qu'elle identifie exclusivement la valeur de chaque champ

au sein d'un enregistrement donné et répond à tous les éléments d'une clé

primaire.

13. Une clé alternative est une clé candidate qui n'a pas été choisie pour servir

de clé primaire de la table.

14. En établissant l'intégrité au niveau de la table, vous garantissez ce qui

suit :

1. Il n'y a pas d'enregistrements en double dans une table.

2. La clé primaire identifie exclusivement chaque enregistrement d'une table.

3. Chaque valeur de clé primaire est unique.

4. Les valeurs de clé primaire ne sont pas nulles.

15. Vous devez revoir les structures initiales des tableaux pour les raisons

suivantes :

1. S'assurer que les sujets appropriés sont représentés dans la base de

données

2. S'assurer que les noms et les descriptions des tables sont adaptés et

significatifs pour tout le monde

3. Pour s'assurer que les noms de champs sont appropriés et significatifs pour

tout le monde
4. Pour vérifier que tous les champs appropriés sont affectés à chaque table

Chapitre 9

1. Les spécifications de terrain sont importantes pour les raisons suivantes :

1. Ils aident à établir et à faire respecter l’intégrité sur le terrain.

2. Ils contribuent à améliorer l’intégrité globale des données.

3. Ils vous obligent à acquérir une compréhension complète de la nature et de

la finalité des données contenues dans la base de données.

4. Ils constituent le « dictionnaire de données » de la base de données.

2. L'intégrité sur le terrain garantit ce qui suit :

1. L'identité et le but d'un champ sont clairs et tous les tableaux dans lesquels

il apparaît sont correctement identifiés.

2. Les définitions de champs sont cohérentes dans toute la base de données.

3. Les valeurs d'un champ sont cohérentes et valides.

4. Les types de modifications, de comparaisons et d'opérations pouvant être

appliquées aux valeurs du champ sont clairement identifiés.

3. Les trois catégories d'éléments dans une spécification de champ

sont générales, physiques et logiques.

4. Les trois types de spécifications sont Unique, Générique et Réplique.

5. Rédiger une description de champ appropriée est extrêmement bénéfique

car cela vous oblige (ainsi que tous les membres de l'organisation) à réfléchir

attentivement à la nature des données qui seront stockées sur le terrain.

6. L' élément Type de données indique la nature des données stockées par le

champ.

7. L' élément Prise en charge des caractères indique le type de caractères

qu'un utilisateur peut saisir dans une valeur de champ donnée.

8. Les types de clés indiqués dans une spécification de champ sont non,

primaires, alternatives et étrangères.

9. Faux. Null ne représente pas un espace : il représente une

valeur manquante ou inconnue .

10. L' élément Range of Values spécifie toutes les valeurs valides possibles

pour un champ.

11. Une règle d'édition désigne à quel moment un utilisateur peut saisir une

valeur dans un champ et s'il peut modifier cette valeur.

12. Vous utilisez une spécification générique pour un champ qui sert de modèle

pour d'autres champs de la base de données.

Chapitre 10

1. Une relation est importante pour les raisons suivantes :

1. Il établit une connexion entre une paire de tables logiquement liées les unes

aux autres.

2. Cela permet d'affiner les structures des tables et de minimiser davantage

les données redondantes.

3. C'est le mécanisme qui vous permet d'extraire des données de plusieurs

tables simultanément.

2. Les trois types de relations sont un à un, un à plusieurs et plusieurs à

plusieurs.

3. La relation plusieurs-à-plusieurs posera le plus de problèmes.

4. Vous pourriez éventuellement rencontrer des problèmes tels que ceux-ci

avec une relation plusieurs-à-plusieurs :

1. Il vous sera fastidieux et quelque peu difficile de récupérer des informations

dans l'une des tables.

2. L'une des tables contiendra une grande quantité de données redondantes.

3. Des données en double existeront dans les deux tables.

4. Il sera difficile d'insérer, de mettre à jour et de supprimer des données.

5. Une relation d'auto-référence est une relation qui existe entre les

enregistrements dans un tableau donné.

6. Vous commencez le processus d' identification des relations entre les

tableaux de la base de données en créant une matrice de toutes les tables.

7. Les deux types de questions que vous pouvez poser pour vous aider à

identifier les relations existantes sont associatives et contextuelles.

8. Vous utilisez un symbole de sténographie 1: n pour désigner une relation un-

à-plusieurs dans la matrice de la table.

9. Vous déterminez quel type de relation existe officiellement entre chaque

paire de tables dans la matrice à l'aide de formules qui correspondent aux trois

définitions de type relation.

dix. Vous établissez une relation un-à-plusieurs en prenant une copie de la clé

primaire du tableau du côté «un» de la relation et en l'intégrant dans la

structure du tableau du côté «beaucoup», où il devient alors une clé

étrangère .

11. Vrai. La récupération des informations des tables avec une relation d'auto-

référence peut être fastidieuse et quelque peu difficile.

12. Vous établissez une relation de plusieurs à plusieurs références comme

vous le feriez pour une relation à double table et plusieurs à plusieurs - avec un

tableau de liaison.
13. Vous affinez les clés étrangères dans la base de données en vous assurant

que chacun est conforme aux éléments d'une clé étrangère.

14. Les deux catégories d'éléments que vous devez modifier pour les

spécifications du champ d'une clé étrangère sont les éléments généraux et les

catégories d'éléments logiques.

15. Une règle de suppression détermine ce que vos SGBDR devraient faire

lorsque vous placez une demande pour supprimer un enregistrement donné

dans le tableau parent de la relation.

16. Les deux types de participation que vous pouvez désigner pour une table

sont obligatoires et facultatives.

17. Le degré de participation indique le nombre minimum d'enregistrements

qu'une table donnée doit avoir associés à un seul enregistrement de la table

associée et le nombre maximum d'enregistrements que la table est autorisée

à associer à un seul enregistrement de la table associée.

18. Une relation atteint l'intégrité au niveau relationnel après avoir vérifié

qu'elle est correctement établie et que ses caractéristiques sont correctement

définies.

Chapitre 11

1. Une règle d'entreprise est une déclaration qui impose une forme de

contrainte sur un aspect spécifique de la base de données, tels que les

éléments dans une spécification de champ pour un champ particulier ou les

caractéristiques d'une relation donnée.

2. Les deux principaux types de règles métier sont orientés vers la base de

données et orientés vers l'application.

3. Non. Les règles métier orientées application imposent des contraintes que

vous ne pouvez pas établir dans la conception logique de la base de données.

4. Les deux catégories de règles commerciales axées sur la base de données

sont spécifiques au champ et spécifiques à la relation.

5. Une règle commerciale spécifique au champ est celle qui impose des

contraintes aux éléments d'une spécification de champ pour un champ

particulier.

6. La contrainte que la règle commerciale impose est testée lorsque vous

essayez d'effectuer l'une des trois actions: insérer un enregistrement dans le

tableau ou une entrée dans un champ, en supprimant un enregistrement du

tableau ou une valeur dans un champ, ou à la mise à jour d'un champ valeur.

7. Vous documentez une règle commerciale en remplissant une feuille de

spécifications de règles commerciales pour la règle.

8. La feuille de spécifications de règles commerciales offre ces avantages:

1. Il vous permet de documenter chaque règle commerciale axée sur la base

de données.

2. Il vous permet de documenter chaque règle commerciale axée sur les

applications.

3. Il fournit une méthode standard pour enregistrer toutes les règles métier.

9. La section des mesures prises d'une feuille de spécifications de règles

commerciales est le domaine où vous indiquez les modifications que vous avez

apportées aux éléments d'une spécification de champ ou à un diagramme de

relations.
10. Un tableau de validation (également appelé tableau de recherche ) stocke

les données que vous utilisez spécifiquement pour implémenter l'intégrité des

données en restreignant la plage de valeurs qui peuvent être utilisées pour un

champ.

11. Les tables de validation comprennent généralement (mais pas toujours)

deux champs: le premier agit comme la clé principale et est ce que vous

utiliserez pour vous aider à appliquer l'intégrité des données, et le second est

simplement un champ non clé qui stocke un ensemble de Valeurs requises par

un autre champ dans la base de données.

12. Vous pouvez utiliser un tableau de validation pour appliquer une contrainte

qu'une règle d'entreprise impose à la plage de valeurs d'un champ donné.

13. Vous devez consulter chaque feuille de spécifications de règles

commerciales pour vous assurer que vous avez correctement établi la règle

qu'il enregistre et que vous avez clairement marqué tous les domaines

appropriés de la feuille.

Chapitre 12

1. Vous pouvez qualifier une vue de table virtuelle car elle extrait les données

des tables de base plutôt que de les stocker seules.

2. Les opinions sont précieuses pour les raisons suivantes :

1. Vous pouvez les utiliser pour travailler simultanément avec les données de

plusieurs tables.

2. Ils reflètent les informations les plus récentes contenues dans les tableaux

de base.

3. Vous pouvez les personnaliser selon les besoins spécifiques d'un individu ou

d'un groupe d'individus.

4. Vous pouvez les utiliser pour contribuer à renforcer l’intégrité des données.

5. Vous pouvez les utiliser à des fins de sécurité ou de confidentialité.

3. Les types de vues que vous pouvez définir lors de la conception de la

structure logique de la base de données sont les vues de données,

d'agrégation et de validation .

4. Chaque fois que vous accédez à une vue, votre SGBDR le reconstruira et le

remplira à nouveau en utilisant les données les plus récentes des tables de

base de la vue.

5. Les spécifications de champ et les règles métier déterminent les types de

modifications que vous pouvez apporter aux données d'une vue.

6. La seule condition que vous devez remplir pour définir une vue de données

multitable est que les tables que vous utilisez pour créer la vue doivent
entretenir une relation les unes avec les autres.

7. Une vue de données ne contient pas sa propre clé primaire car ce n'est pas

une table ; une vraie table stocke les données et nécessite une clé primaire

pour servir d'identifiant unique pour chacun de ses enregistrements.

8. Le but d'une vue globale est d'afficher les informations produites en

agrégeant un ensemble particulier de données d'une manière spécifique.

9. Somme, Moyenne (moyenne arithmétique), Minimum,

Maximum et Nombre sont les fonctions d'agrégation les plus courantes que
vous pouvez appliquer à un ensemble de données.

10. Un champ de regroupement est un champ de données dans une vue

agrégée qui « regroupe » plusieurs instances d'une valeur donnée en une seule

instance de la valeur.
11. Faux. Vous ne pouvez pas modifier les données dans une vue agrégée car

elles sont entièrement composées de champs de regroupement et de champs

calculés.

12. La différence entre une table de validation et une vue de validation réside

dans leur construction : une table de validation stocke ses propres données,

tandis qu'une vue de validation extrait les données de ses tables de base.

13. Vous devez garder les points suivants à l’esprit lorsque vous identifiez les

exigences en matière d’affichage :

1. Révisez vos notes avec le groupe.

2. Passez en revue les exemples de saisie de données, de rapports et de

présentations que vous avez rassemblés au cours des premières étapes du

processus de conception.

3. Examinez les tableaux et les sujets qu’ils représentent.

4. Analysez les relations entre les tables.

5. Étudiez les règles commerciales.

14. Vous devez utiliser des champs calculés lorsqu'ils fourniront des

informations pertinentes et significatives ou lorsqu'ils amélioreront la manière

dont la vue utilise ses données.

t
15.
a Vous définissez une vue qui affiche uniquement les livres de science-fiction
ben appliquant un filtre au champ approprié dans la vue.
l
e
16. Vous devez compléter une feuille de spécifications de vue pour chaque vue
d
de la base de données car c'est sur cette feuille que vous enregistrerez les
e
scaractéristiques de la vue.
P
ar
rem
dqac
oum
ht
seèei
utrè
erc
eh
se
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
A : Réponses aux questions de révision
B: Diagramme du processus de conception de la base de données
C : Directives de conception
53m restants

Schéma du processus de conception de base de données

Le diagramme des pages suivantes vous fournit une carte de l’ensemble du

processus de conception de base de données. Il indique chaque phase de

conception, les procédures au sein de la phase, les tâches au sein de la

procédure et, dans certains cas, les sous-tâches au sein d'une tâche.

Cette légende montre le type de symboles que vous verrez dans le diagramme.
rtd
qP
ouaeAller au contenu
sercbLes sujets
uahlCommencer à apprendre
En
em vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
èr
B: Diagramme du processus de conception de la base de données
tcdC : Directives de conception
rhe D : Formulaires de documentation
es
44 minutes restantes
s
m
a
t
i
è
r
e
s

Directives de conception

Voici, par ordre alphabétique, les différents ensembles de directives de

conception qui apparaissent tout au long du livre.

Définir et établir des règles métier spécifiques au domaine

1. Sélectionnez un tableau.

2. Passez en revue chaque champ et déterminez si cela nécessite des

contraintes.

3. Définir les règles métier nécessaires pour le terrain.

4. Établissez les règles en modifiant les éléments de spécification de champ

appropriés.

5. Déterminez quelles actions testent la règle.

6. Enregistrez la règle sur une feuille de spécifications des règles métier.

Définir et établir des règles commerciales spécifiques aux
relations

1. Sélectionnez une relation.

2. Passez en revue la relation et déterminez si elle nécessite des contraintes.

3. Définissez les règles commerciales nécessaires pour la relation.

4. Établissez la règle en modifiant les caractéristiques de la relation

appropriées.

5. Déterminez quelles actions testeront la règle.

6. Enregistrez la règle sur une feuille de spécifications des règles métier.

Éléments d'une clé de candidat

• Il ne peut pas s'agir d'un champ en plusieurs parties.

• Il doit contenir des valeurs uniques.

• Il ne peut pas contenir de valeurs Null.

• Sa valeur ne peut pas entraîner une violation des règles de sécurité ou de

confidentialité de l'organisation.

• Sa valeur n'est pas facultative en tout ou en partie.

• Il comprend un nombre minimum de champs nécessaires pour définir

l'unicité.

• Ses valeurs doivent identifier de manière unique et exclusive chaque

enregistrement de la table.

• Sa valeur doit identifier exclusivement la valeur de chaque champ au sein

d'un enregistrement donné.

• Sa valeur ne peut être modifiée que dans des cas rares ou extrêmes.

Éléments d'une clé étrangère

• Elle porte le même nom que la clé primaire à partir de laquelle elle a été

copiée.
• Il utilise une réplique des spécifications de champ pour la clé primaire à

partir de laquelle elle a été copiée.

• Il tire ses valeurs de la clé primaire à laquelle il se réfère.

Éléments d'une clé primaire

• Il ne peut pas s'agir d'un champ en plusieurs parties.

• Il doit contenir des valeurs uniques.

• Il ne peut pas contenir de valeurs Null.

• Sa valeur ne peut pas entraîner une violation des règles de sécurité ou de

confidentialité de l'organisation.

• Sa valeur n'est pas facultative en tout ou en partie.

• Il comprend un nombre minimum de champs nécessaires pour définir

l'unicité.

• Ses valeurs doivent identifier de manière unique et exclusive chaque

enregistrement de la table.

• Sa valeur doit identifier exclusivement la valeur de chaque champ au sein

d'un enregistrement donné.

• Sa valeur ne peut être modifiée que dans des cas rares ou extrêmes.

Règles d'établissement d'une clé primaire

• Chaque table doit avoir une (et une seule) clé primaire.

• Chaque clé primaire de la base de données doit être unique : deux tables ne

doivent pas avoir la même clé primaire, sauf si l'une d'elles est une table de

sous-ensemble.

Éléments du champ idéal

• Il représente une caractéristique distincte du sujet du tableau.

• Il ne contient qu'une seule valeur.

• Il ne peut pas être déconstruit en composants plus petits.

• Il ne contient pas de valeur calculée ou concaténée.

• Il est unique dans toute la structure de la base de données.

• Il conserve la majorité de ses caractéristiques lorsqu'il apparaît dans

plusieurs tableaux.

Éléments de la table idéale

• Il représente un sujet unique, qui peut être un objet ou un événement.

• Il possède une clé primaire.

• Il ne contient pas de champs en plusieurs parties ou à valeurs multiples.

• Il ne contient pas de champs calculés.

• Il ne contient pas de champs en double inutiles.

• Il ne contient qu’un minimum absolu de données redondantes.

Intégrité au niveau du terrain

L'intégrité au niveau du terrain garantit les éléments suivants :

• L'identité et le but d'un champ sont clairs et tous les tableaux dans lesquels

il apparaît sont correctement identifiés.

• Les définitions de champs sont cohérentes dans toute la base de données.

• Les valeurs d'un champ sont cohérentes et valides.

• Les types de modifications, de comparaisons et d'opérations pouvant être

appliquées aux valeurs du champ sont clairement identifiés.

Lignes directrices pour rédiger une description de champ

• Utilisez une déclaration qui identifie avec précision le champ et indique

clairement son objectif.

• Rédigez une déclaration claire et succincte.

• Évitez de reformuler ou de reformuler le nom du champ.

• Évitez d'utiliser du jargon technique, des acronymes ou des abréviations.

• N’incluez pas d’informations spécifiques à la mise en œuvre.

• Ne faites pas dépendre cette description de la description d’un autre champ.

• N'utilisez pas d'exemples.

Lignes directrices pour composer une description de tableau

• Incluez une déclaration qui définit avec précision le tableau.

• Incluez une déclaration expliquant pourquoi ce tableau est important pour

l’organisation.

• Rédigez une description claire et succincte.

• N'incluez pas d'informations spécifiques à l'implémentation dans la

description de votre table, telles que la manière et l'endroit où la table est

utilisée.

• Ne faites pas dépendre la description d'une table de la description d'une

autre table.

• N'utilisez pas d'exemples dans une description de tableau.

Lignes directrices pour la création de noms de champs

• Créez un nom unique et descriptif qui ait du sens pour l'ensemble de

l'organisation.

• Créez un nom qui identifie avec précision, clarté et sans ambiguïté la

caractéristique qu'un champ représente.

• Utilisez le nombre minimum de mots nécessaire pour transmettre la

signification de la caractéristique représentée par le champ.

• N'utilisez pas les acronymes et utilisez judicieusement les abréviations.

• N'utilisez pas de mots qui pourraient confondre la signification du nom du

champ.

• N'utilisez pas de noms qui identifient implicitement ou explicitement plus

d'une caractéristique.

• Utilisez la forme singulière du nom.

Directives pour la création de noms de table

• Créez un nom unique et descriptif qui ait du sens pour l'ensemble de

l'organisation.
• Créez un nom qui identifie avec précision, clarté et sans ambiguïté le sujet

du tableau.

• Utilisez le nombre minimum de mots nécessaire pour transmettre le sujet du

tableau.

• N'utilisez pas de mots qui véhiculent des caractéristiques physiques.

• N'utilisez pas d'acronymes et d'abréviations.

• N'utilisez pas de noms propres ou d'autres mots qui restreindraient

indûment les données pouvant être saisies dans le tableau.

• N'utilisez pas de nom qui identifie implicitement ou explicitement plus d'un

sujet.

• Utilisez la forme plurielle du nom.

Identifier les relations

Utilisez cette procédure pour identifier la relation officielle entre une paire de

tables dans une matrice de table :

1. Sélectionnez une paire de tables et notez l'entrée à la jonction de la

première table et de la deuxième table.

2. Localisez le deuxième tableau du même côté de la matrice sur laquelle vous

travaillez et notez l'entrée et la jonction entre celui-ci et le premier tableau

du côté opposé de la matrice.

3. Appliquez la formule appropriée (affichée ci-dessous) aux deux entrées et

identifiez la relation officielle entre les tables.

1:1 + 1:1 = 1:1

1:N + 1:1 = 1:N

1:N + 1:N = M:N

4. Diagramme de la relation de la manière appropriée.

5. Rayez les deux entrées sur la matrice.

Identifier les exigences de vue

Utilisez cette procédure pour identifier les exigences de vue de votre

organisation.

• Passez en revue vos notes avec le groupe de représentants des

utilisateurs/gestionnaires.

• Passez en revue les exemples de saisie de données, de rapports et de

présentations que vous avez rassemblés au cours des premières étapes du

processus de conception.

• Examinez les tableaux et les sujets qu’ils représentent.

• Analysez les relations entre les tables.

• Étudiez les règles commerciales.

Lignes directrices pour les entretiens

Lignes directrices pour les participants

• Faites prendre conscience aux participants de vos intentions.

• Faites savoir aux participants que vous appréciez leur participation à

l'entretien et que leurs réponses aux questions de l'entretien sont

précieuses pour le projet de conception global.

• Assurez-vous que tout le monde comprend que vous êtes l'arbitre officiel en

cas de litige.

Lignes directrices pour les intervieweurs

• Choisissez une plateforme de réunion appropriée pour mener votre réunion.

• Fixez une limite raisonnable et pratique pour le nombre de personnes

participant à chaque entretien.

• Mener des entretiens séparés pour les utilisateurs et la direction.

• Lorsque vous devez interviewer plusieurs groupes de personnes, désignez

un chef de groupe pour chaque groupe.

• Préparez vos questions avant l’entretien.

• Si vous n'êtes pas très doué pour prendre des notes, confiez cette tâche à

un transcripteur fiable pour chaque entretien ou informez le groupe à

l'avance que vous allez enregistrer l'entretien à des fins de référence.

• Accordez à chacun votre attention égale et sans partage.

• Gardez le rythme de l’entretien en mouvement.

• Gardez toujours le contrôle de l’entretien.

Énoncés de mission

Un énoncé de mission bien rédigé présente les attributs suivants :

• Il exprime son point de vue de manière succincte et immédiate.

• Il évite les déclarations ou les détails inutiles et est bien défini.

• Il évite les expressions ou phrases qui décrivent explicitement des tâches

spécifiques.
• Cela a du sens pour vous (le développeur de la base de données) et pour

ceux pour qui vous concevez la base de données.

Objectifs de la mission

Un objectif de mission bien rédigé possède les attributs suivants.

• Il comprend une phrase déclarative qui définit clairement une tâche

générale et est exempte de détails inutiles.

• Il s’exprime en termes généraux, succincts et sans ambiguïté.

• Cela a du sens pour vous et pour ceux pour qui vous concevez la base de

données.

Intégrité au niveau des relations

Ce type d’intégrité garantit ce qui suit.

• La connexion entre les deux tables (ou champs clés) dans une relation est

solide.

• Vous pouvez insérer de nouveaux enregistrements dans chaque table de

manière significative.

• Vous pouvez supprimer un enregistrement existant sans produire d'effets

indésirables.

• Il existe une limite significative au nombre d'enregistrements pouvant être

interconnectés au sein de la relation.

Résolution d'un champ à valeurs multiples

Utilisez cette procédure générique pour résoudre un champ à plusieurs

valeurs :

1. Supprimez le champ de la table et utilisez-le comme base pour une nouvelle

table. Si nécessaire, renommez le champ conformément aux directives de

nom de champ que vous avez apprises précédemment.

2. Prenez la clé primaire de la table d'origine et intégrez-la dans la nouvelle

structure de table. Ce champ remplira deux fonctions spécifiques dans la

nouvelle table : il fera partie de la clé primaire composite de la table et il

servira de clé étrangère permettant d'établir la relation entre la nouvelle

table et la table d'origine.

3. Attribuez un nom, un type et une description appropriés à la nouvelle table

et ajoutez-la à la liste des tables finales.

Intégrité au niveau de la table

Ce type d'intégrité garantit les éléments suivants :

• Il n'y a pas d'enregistrements en double dans une table.

• La clé primaire identifie exclusivement chaque enregistrement d'une table.

• Chaque valeur de clé primaire est unique.

• Les valeurs de clé primaire ne sont pas nulles.

rtd
qP
ouaeAller au contenu
sercbLes sujets
uahlCommencer à apprendre
En
em vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
èr
C : Directives de conception
tcdD : Formulaires de documentation
rhe E : Symboles des diagrammes de conception de base de données
es
44 minutes restantes
s
m
a
t
i
è
r
e
s

Formulaires de documentation

J'ai fourni ici des copies vierges de la feuille de spécifications de champ, de la

feuille de spécifications de règles métier et de la feuille de spécifications de

vue pour que vous puissiez les copier et les utiliser dans vos projets de base de

données.
rtd
qP
ouaeAller au contenu
sercbLes sujets
uahlCommencer à apprendre
En
em vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
èr
D : Formulaires de documentation
tcdE : Symboles des diagrammes de conception de base de données
rhe F : Échantillons de conceptions
es
44 minutes restantes
s
m
a
t
i
è
r
e
s

Symboles des diagrammes de conception de base de données

Les symboles que j'ai utilisés tout au long du livre pour schématiser les

structures de données, les relations, les caractéristiques des relations et les

désignations clés sont présentés ici pour une référence rapide et facile.
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
E : Symboles des diagrammes de conception de base de données
F : Échantillons de conceptions
G : Sur la normalisation
26 minutes restantes

Exemples de conceptions

J'ai fourni ces exemples de conceptions pour vous servir d' idées pour les bases

de données que vous souhaiterez ou devrez peut-être créer. J'insiste sur le

mot idées car cinq personnes peuvent regarder le même design et proposer

cinq variantes distinctes en fonction de leurs besoins, de leurs antécédents et

de leurs points de vue personnels. N'oubliez pas qu'il n'y a pas de bonne ou de

mauvaise façon de concevoir une base de données donnée, mais vous devez

vous assurer que les tables, les champs, les relations et les vues sont tous

conformes aux directives que vous avez apprises dans ce livre.

J'ai intentionnellement omis tous les champs de chaque table, à l'exception des

champs de clé primaire et étrangère, car je ne voulais pas vous influencer

grandement sur la façon dont les tables devraient être remplies. J'ai également

omis la majorité des caractéristiques relationnelles pour la même raison.

Si vous voyez une conception que vous pourriez utiliser, exécutez-la tout au

long du processus de conception de base de données et traitez-la comme une

base de données existante. À la fin du processus, vous devriez disposer d’une

base de données adaptée à vos besoins.

t
a
b
l
e

d
e
s
P
ar
rem
ac
ht
m
dq
èeiqd
ou
trèuo
se
rces
u
ehu
e
se
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
F : Échantillons de conceptions
G : Sur la normalisation
H : Lecture recommandée
8 millions restants

Sur la normalisation

Je chérirai toujours les premières idées fausses que j’avais à votre sujet.

-INCONNU _

Les gens se demandent souvent pourquoi je n'ai pas abordé la normalisation

dans les éditions précédentes de ce livre, étant donné qu'elle fait partie de la

conception de bases de données traditionnelles depuis si longtemps. Le fait est

qu’il est inutile pour moi d’en discuter pour deux raisons :

1. Une discussion approfondie qui rendrait justice au sujet dépasse la portée

de ce travail, en particulier compte tenu de la méthodologie de conception

non traditionnelle que je présente ici et de la nature « pour les simples

mortels » de l’approche du matériau.

2. De toute façon, la normalisation est intégrée à mon processus de

conception. (Je vais vous expliquer comment dans un instant.)

Je reçois toujours des questions sur ce problème et je vois des commentaires à

ce sujet sur la page Amazon.com du livre . J'ai donc décidé d'inclure une

discussion sur la manière dont le processus de normalisation traditionnel est

intégré dans mon processus de conception. Ceux d'entre vous qui étudient

actuellement le processus traditionnel de conception et de normalisation

comprendront probablement plus clairement ma méthodologie de conception

après avoir lu ce document.

Veuillez noter. . .

Je souhaite clarifier quelques points avant de poursuivre la lecture :

• Veuillez lire « La méthode de conception présentée dans ce livre » et les

sections « Normalisation » vers la fin du chapitre 2 , « Objectifs de

conception »avant de lire quoi que ce soit d'autre dans cette annexe. Ces
sections fournissent une explication globale du pourquoi et du comment j'ai

élaboré ma méthodologie de conception. Ils vous fournissent également le

contexte dont vous avez besoin pour les points dont je discute dans les

sections qui suivent.

• Il ne s'agit pas d'une discussion formelle ou d'un didacticiel sur le

processus de normalisation traditionnel. J'ai recommandé des livres

dans l'Annexe H , « Lectures recommandées », qui traitent de ce sujet assez

bien et de manière très approfondie.

• Je suppose que vous comprenez déjà le processus de normalisation

traditionnel et ses concepts et terminologies associés. Tout au long de la

durée de vie de ce livre, j'ai constaté que les seules personnes

généralement intéressées par cette discussion sont soit des programmeurs

d'applications de bases de données, des personnes connaissant déjà la

normalisation, ou des étudiants qui étudient la normalisation. Ainsi, je

suppose que vous appartenez à un ou plusieurs de ces groupes si vous lisez

cette annexe.

• Il n’existe pas de correspondance littérale entre le processus de

normalisation dans son ensemble et ma méthodologie de conception. La

normalisation est effectivement intégrée à ma méthodologie, mais pas de

manière séquentielle distincte. Alors que la normalisation est une étape

spécifique du processus de conception logique traditionnel, elle est intégrée

de manière transparente tout au long du processus de conception dans ma
méthodologie. Cela deviendra plus clair à mesure que vous lirez le matériel.
• Ma méthodologie de conception produira des tableaux entièrement

normalisés. Cela n’est vrai, cependant, que si vous suivez ma méthodologie

aussi fidèlement que vous le feriez avec la méthodologie traditionnelle ou

toute autre méthodologie. Prendre des raccourcis ou ne pas suivre certaines

parties du processus entraînera de mauvaises structures de table et une

mauvaise intégrité. Mais cela est également vrai si vous faites la même

chose avec toute autre méthodologie, traditionnelle ou autre.

J'espère que vous venez de terminer la lecture des deux sections du chapitre

2 que je vous ai signalées dans le premier point. Je vais maintenant vous

expliquer comment j'ai intégré la normalisation dans ma méthodologie de

conception.
Un bref récapitulatif

Je vais commencer par un bref aperçu de la façon dont j'ai élaboré ma

méthodologie, que vous avez apprise en lisant ces deux sections du chapitre

2.

Commençons cependant par passer en revue les étapes générales de la

méthode de conception traditionnelle :

• Identifiez les principales entités.

• Identifiez les types de relations.

• Déterminez les clés primaires.

• Déterminez les clés étrangères.

• Associez des attributs à des types d’entité ou de relation.

• Déterminez les domaines d’attributs.

• Validez le modèle à l’aide de la normalisation.

• Définir les contraintes d’intégrité.

Les deux choses qui m'ont le plus dérangé dans cette méthodologie étaient le

processus de normalisation (dans son ensemble) et les itérations apparemment

infinies nécessaires pour arriver à une conception appropriée.

Je savais déjà que le but de la normalisation est de transformer un ensemble

de tables mal ou mal conçues en tables aux structures saines. J'ai également

compris le processus : prenez un tableau donné et testez-le par rapport à des

formulaires normaux pour déterminer s'il est correctement conçu. S'il n'est pas
conçu correctement, apportez les modifications appropriées, testez-le à

nouveau et répétez l'ensemble du processus jusqu'à ce que la structure du

tableau soit saine. La figure G.1 montre comment j'ai visualisé le processus à

ce stade.
Figure G.1 Comment j'ai perçu le processus général de normalisation.

Il existe un certain nombre de formes normales, et chacune est utilisée pour

tester un ensemble particulier de problèmes ou de caractéristiques, tels que

des anomalies de modification, des dépendances fonctionnelles, des

dépendances transitives, des dépendances à valeurs multiples, des

dépendances de jointure, des domaines et des clés. Le problème avec les

formes normales est qu’elles peuvent être assez déroutantes pour quiconque

n’a pas pris le temps d’étudier la théorie formelle des bases de données

relationnelles.

À un moment donné, je me suis demandé : « Pourquoi prenons-nous le temps

de créer la base de données aux trois quarts du processus, de nous arrêter

brutalement, puis de déterminer si nous avons conçu nos structures

correctement ? Je pensais que c'était une façon ridicule de faire les choses.
En gardant à l’esprit l’objectif de la normalisation, j’ai ensuite posé les

questions suivantes :

1. Si nous supposons qu'une table entièrement normalisée est conçue

correctement et efficacement, ne devrions-nous pas être en mesure

d'identifier les caractéristiques spécifiques d'une telle table et de les

considérer comme les attributs d'une structure de table idéale ?

2. Ne pourrions-nous pas alors utiliser cette table idéale comme modèle pour

toutes les tables que nous créons pour la base de données tout au long du

processus de conception ?
La réponse à ces deux questions, bien sûr, est « oui », j’ai donc utilisé ce

principe comme base pour ma « nouvelle » méthodologie de conception. J'ai

d'abord compilé des ensembles distincts de lignes directrices pour créer des

structures sonores en identifiant les caractéristiques finales d'une base de

données bien définie qui a réussi les tests de chaque forme normale. J'ai

ensuite effectué quelques tests, en utilisant les nouvelles directives, pour créer

des structures de tables pour une nouvelle base de données et pour corriger

des défauts dans les structures de tables d'une base de données existante. Ces

tests se sont très bien déroulés, j'ai donc décidé d'appliquer cette technique à

l'ensemble de la méthodologie de conception traditionnelle. J'ai formulé des

lignes directrices pour résoudre d'autres problèmes associés à la méthode de

conception traditionnelle, tels que les domaines, les sous-types, les relations,

l'intégrité des données et l'intégrité référentielle. Après avoir suivi les nouvelles

directives, j'ai effectué davantage de tests et j'ai constaté que ma

méthodologie fonctionnait plutôt bien.

Ma méthodologie de conception supprime de nombreux aspects de la

méthodologie de conception traditionnelle que les nouveaux développeurs de

bases de données trouvent intimidants. Par exemple, la normalisation, au sens

traditionnel, est désormais transparente pour le développeur car elle est

intégrée (via les nouvelles directives) tout au long du processus de

conception. La méthodologie est également claire et facile à mettre en œuvre,

ce qui, je pense, est dû au fait que les lignes directrices sont rédigées dans un

anglais simple, ce qui les rend faciles à comprendre pour la plupart des gens.

Je pense que le processus de conception d’une base de données n’est pas et

ne devrait pas être difficile à comprendre. Tant que le processus est présenté

de manière simple et que chaque concept ou technique est clairement

expliqué, n'importe qui devrait être capable de concevoir correctement une

base de données.
Comment la normalisation est intégrée dans ma
méthodologie de conception

Comme je l'ai mentionné plus tôt, il n'existe pas de correspondance directe

entre la normalisation et ma méthodologie de conception. Au contraire, divers

éléments de ma méthodologie travaillent ensemble de manière transparente

pour résoudre les problèmes habituellement abordés par le processus de

normalisation. Mon approche aborde et résout en outre et de manière

transparente d'autres problèmes de conception traditionnels tels que les

valeurs scalaires, les déterminants, les dépendances fonctionnelles, les

domaines, les anomalies de modification, l'intégrité référentielle, la cardinalité

et l'optionnalité.

Examinons d'abord le tableau G.1 et considérons les problèmes fondamentaux

abordés par chaque formulaire normal avant de vous montrer comment mon

système les traite spécifiquement.

Tableau G.1 Questions fondamentales abordées par chaque forme normale

Première forme Traite les dépendances fonctionnelles et à valeurs

normale multiples

Deuxième forme Traite les dépendances fonctionnelles, les

normale dépendances transitives et les champs calculés

Troisième forme Traite les dépendances fonctionnelles et les anomalies

normale de modification

Quatrième forme
Traite les dépendances à valeurs multiples
normale

Cinquième forme
Traite les dépendances de jointure
normale

Sixième forme normale Principalement utilisé sur les données spatiales

Boyce/Codd Forme Traite les clés déterminées et candidates
normale

Forme normale de
Traite les domaines et les clés
domaine/clé

En gardant cela à l’esprit (ainsi que les autres problèmes auxquels j’ai fait

référence plus tôt), je me suis efforcé à l’origine de développer une

méthodologie de conception intégrant tout cela et l’abordant de manière plus

efficace et beaucoup moins répétitive. Je souhaitais également que ma

méthodologie soit claire et facilement compréhensible par quiconque décide de

l'adopter. C'est pourquoi j'ai spécifiquement décidé de m'éloigner du jargon

traditionnel et de l'approche mathématique et d'utiliser plutôt un anglais

simple pour décrire les processus que j'ai développés.

Le tableau G.2 montre comment les différents composants de ma

méthodologie de conception répondent aux problèmes traditionnels de

normalisation et de conception.

Tableau G.2 Comment ma méthodologie répond aux problèmes de

normalisation et de conception traditionnels

Composante de ma
Problèmes de normalisation ou de conception
méthodologie de
traditionnels auxquels il répond
conception

Spécifications des règles

Domaines logiques, tables de validation
métier

Éléments d'une clé Dépendances fonctionnelles, dépendances

candidate/primaire multivaluées, dépendances transitives, déterminés

Éléments d'une clé Clés étrangères, intégrité référentielle, anomalies de

étrangère modification

Éléments du champ Valeurs scalaires, champs à plusieurs valeurs et en

idéal plusieurs parties, valeurs calculées

Éléments de la table Dépendances fonctionnelles, dépendances à valeurs

Composante de ma
Problèmes de normalisation ou de conception
méthodologie de
traditionnels auxquels il répond
conception

multiples, dépendances transitives, dépendances de

idéale jointure, champs en double, données en double et

redondantes, anomalies de modification, sous-types

Intégrité au niveau du Valeurs scalaires, domaines physiques, domaines

terrain logiques, intégrité du domaine

Valeurs scalaires, domaines physiques, domaines

Spécifications du terrain
logiques, intégrité du domaine

Caractéristiques de la
Cardinalité, optionnalité, règles de suppression
relation

Intégrité au niveau des

Intégrité référentielle, clés étrangères
relations

Résolution des champs

Valeurs scalaires, domaines logiques
multiparties

Résolution de champs à
Valeurs scalaires, domaines logiques
valeurs multiples

Intégrité au niveau de la Intégrité de la clé primaire, enregistrements en

table double, dépendances fonctionnelles

Comme je l'ai toujours dit, mon approche traite effectivement de tous les

problèmes que vous aborderiez généralement avec le processus de

normalisation, et elle produira des tableaux entièrement

normalisés. Cependant, cela ne se fera que si vous suivez ma méthodologie

aussi fidèlement que vous le feriez avec la méthodologie traditionnelle ou toute

autre méthodologie. Gardez à l'esprit que vous traitez réellement tous ces

problèmes lorsque vous développez la base de données au lieu d'attendre de

les résoudre jusqu'à ce que vous ayez environ les deux tiers du processus selon

la méthode traditionnelle. J'ai trouvé que c'était une bien meilleure approche

de conception : il y a moins de répétitivité et la conception de la base de

données prend certainement moins de temps.

Conception logique versus conception physique et mise en

œuvre

On me demande parfois pourquoi je n'ai pas inclus davantage de discussions

sur SQL et les problèmes d'implémentation tels que l'indexation, le

partitionnement et la distribution. La réponse est assez simple : j'ai toujours

pensé que le processus de conception logique et les processus de conception

physique et de mise en œuvre devaient être séparés.

Je continue de croire que de nombreuses personnes tombent involontairement

dans le piège de concevoir une base de données basée uniquement sur le

logiciel SGBDR qu'ils utiliseront pour sa mise en œuvre. Dans de nombreux cas,

ils le font parce qu’ils sont déjà assez familiers et compétents avec un SGBDR

particulier ou que leur entreprise ou organisation utilise déjà un SGBDR

particulier. Il s’agit d’une approche peu judicieuse que vous devriez éviter

(autant que possible) pour plusieurs raisons :

• Vous prendrez probablement des décisions de conception en fonction de vos

perceptions de ce que votre SGBDR peut ou ne peut pas faire. Par exemple,
vous pouvez décider de ne pas imposer un certain degré de participation

pour une relation donnée parce que vous pensez que le SGBDR ne vous en

donne pas les moyens.

• Vous laisserez par inadvertance le SGBDR dicter la conception de la base de

données, au lieu de piloter la conception strictement en fonction des

besoins en informations de l'organisation. Cela se produit généralement
lorsque vous découvrez que votre SGBDR ne fournit qu'une prise en charge

limitée pour certains aspects de la base de données, tels que les

spécifications de champ et les caractéristiques des relations.

• Votre conception sera limitée par votre connaissance du SGBDR. Par

exemple, vous pouvez décider de ne pas mettre en œuvre les

caractéristiques relationnelles simplement parce que vous ne savez pas

comment le faire.

• Votre conception sera limitée par vos compétences avec votre SGBDR. Votre

niveau de compétence affecte l'efficacité avec laquelle vous pouvez mettre

en œuvre divers aspects de la base de données, tels que les spécifications

de champ et les règles métier.

• L'utilisation de cette approche pour concevoir une base de données entraîne

généralement une conception structurelle incorrecte, une intégrité des

données insuffisante et des problèmes de données incohérentes et
d'informations inexactes. Définir une base de données dans un SGBDR peut
être trompeusement simple. Vous pouvez créer une base de données qui

fonctionne, mais vous aurez très probablement une mauvaise conception

sans le savoir.

• En fin de compte, le SGBDR que vous connaissez et aimez si bien n’est

peut-être pas adapté aux exigences de base de données de votre

organisation.
Je pense que vous devez toujours concevoir la structure logique de votre base

de données sans tenir compte d'un SGBDR. Ce faisant, vous êtes plus

susceptible de concevoir une structure solide, car vous vous concentrerez sur

les besoins en informations de l'organisation. Une fois votre conception

terminée, vous pouvez alors déterminer clairement comment vous devez

implémenter la base de données (application mono-utilisateur, client/serveur,

basée sur le Web, etc.) et quel SGBDR vous devez utiliser pour faciliter la mise

en œuvre.

(Le contenu précédent se trouve dans la section « Conception de base de

données basée sur le logiciel de base de données » du chapitre 14 ,
« Mauvaise conception : ce qu'il ne faut pas faire », mais j'ai pensé qu'il valait
la peine de le répéter ici.)

J'espère que cela dissipera enfin toute confusion et répondra à toutes vos

questions concernant ma méthodologie de conception et ma normalisation. J'ai

certainement atteint mon objectif si vous comprenez au moins mon approche

un peu plus clairement et voyez comment elle aborde les mêmes problèmes

que la normalisation.

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s
Aller au contenu
Les sujets
Commencer à apprendre
En vedette
Recherchez plus de 50 000 cours, événements, titres et bien plus encore
H : Lecture recommandée
Glossaire
Les références
8 millions restants

Glossaire

Récupération d'informations ad hoc Processus d'utilisation de requêtes ad

hoc pour récupérer des informations qui n'apparaissent actuellement dans

aucun rapport ou écran de gestion de données existant.

Requête ad hoc Une requête non prédéfinie que vous posez à l'application de
base de données.

Fonction d'agrégation Un extrait de code de programmation qui exécute un

type particulier d'agrégation mathématique sur un ensemble de données et

renvoie une valeur unique.

Vue agrégée Une vue utilisée pour afficher des informations produites en
agrégeant un ensemble particulier de données d'une manière spécifique.

Clé alternative Clé candidate qui n'a pas été désignée comme clé primaire.
Base de données analytique Type de base de données qui stocke des
données statiques et est utilisée lorsqu'il est nécessaire de suivre des

tendances, d'afficher des données statistiques sur une longue période ou de

faire des projections commerciales tactiques ou stratégiques ; il est

généralement associé à OLAP.

Application Logiciel commercial ou personnalisé généralement hébergé sur

un appareil personnel tel qu'un smartphone et utilisé pour fournir une interface

conviviale pour une base de données.

Application Un logiciel commercial ou personnalisé généralement hébergé sur

un ordinateur personnel ou une tablette PC et utilisé pour fournir une interface

conviviale pour une base de données.

Développement d'applications Processus de conception et de création

d'une application qui servira d'interface utilisateur pour une base de données.

Règle métier orientée application Règle qui impose des contraintes que
vous devez établir dans la conception physique de la base de données ou dans

la conception de l'application de base de données.

Programme d'application Logiciel commercial ou personnalisé qui sert

d'interface utilisateur à une base de données.

Clé de candidat artificielle Un champ créé dans le seul but de servir de clé
de candidat. Son existence est due à l’absence de clés candidates « naturelles

» dans le tableau.

Table associative Voir Table de liaison .

Attribut L'équivalent d'un champ dans le modèle relationnel.

Tables de base Tables qui constituent la base d'une vue.

Spécification de règle métier Représente toutes les caractéristiques d'une

règle métier, telles que l'énoncé de la règle, la contrainte qu'elle impose, les

structures qu'elle affecte, etc.

Règles métier Restrictions ou limitations sur certains aspects d'une base de

données en fonction de la manière dont une organisation perçoit et utilise ses

données.

Champ calculé Champ qui contient une valeur de texte concaténée ou le

résultat d'une expression mathématique.

Liste des champs calculés Une liste de champs qui peuvent être définis
uniquement dans un SGBDR. (Rappelez-vous que vous ne pouvez pas définir de

champs calculés dans une structure de table.)

Cardinalité Type de relation qui existe entre une paire de tables dans une
base de données relationnelle. Voir Relation .

Table enfant Dans une relation donnée, table contenant des enregistrements
qui dépendent explicitement de l'existence d'enregistrements dans la table

associée.

SGBDR client/serveur Type de SGBDR dans lequel les données résident sur
un ordinateur agissant comme serveur de base de données et les utilisateurs

interagissent avec les données via des applications résidant sur leur propre

ordinateur, appelées client de base de données.

Question fermée Une question qui a un ensemble définitif et fini de

réponses. Ce type de question laisse peu de place à d’autres questions de

suivi.
Cloud Type de stockage qui repose sur un pool partagé de ressources
physiques et/ou virtuelles. Il vous permet de stocker et d'accéder à des

données et des programmes via Internet ou un service Internet, ce qui rend

inutile leur conservation sur le disque dur de votre ordinateur. Vous pouvez

accéder à un cloud n’importe où et à tout moment tant que vous disposez

d’une connexion Internet.

Clé primaire composite Clé primaire composée de deux champs ou plus.

Données Les valeurs stockées dans la base de données.

Cohérence des données Chaque occurrence d'une valeur de champ donnée

dans l'ensemble de la base de données est exactement la même.

Formulaire de saisie de données Un écran dans un programme

d'application utilisé pour rassembler et collecter des données.

Intégrité des données Un ensemble de règles ou de lignes directrices qui

régissent la validité, la cohérence et l'exactitude des données dans une base

de données. Les quatre types d'intégrité des données sont les règles de niveau

table, de champ, de relation et de gestion.

Structure de données Construction particulière utilisée pour stocker des

données, telles qu'un champ ou une table.

Table de données Une table qui stocke les données utilisées pour fournir des
informations ; c'est le type de table le plus courant dans une base de données

relationnelle.

Vue de données Une vue utilisée pour examiner et manipuler les données
d'une ou plusieurs tables de base.
Application de base de données Voir Application .

Programme d'application de base de données Voir Programme

d'application .

Processus de conception de base de données Ensemble d'actions

requises pour concevoir la structure logique d'une base de données.

Règle métier orientée base de données Règle qui impose des contraintes
que vous pouvez établir dans la conception logique de la base de données.

SGBD (Database Management System) Un logiciel utilisé pour créer,

maintenir, modifier et manipuler une base de données.

Degré de participation Considérant une relation donnée entre une paire de

tables au sein d'une base de données relationnelle, il s'agit du nombre

minimum et maximum d'enregistrements qu'une table peut avoir associé à un

seul enregistrement dans la table associée.

Règle de suppression Règle qui détermine ce que le SGBDR doit faire

lorsqu'un utilisateur demande la suppression d'un enregistrement donné dans

la table parent d'une relation.

Domaine Voir Spécification du champ .

Intégrité du domaine Voir Intégrité au niveau du champ .

Données en double Valeur de clé non primaire qui apparaît dans plusieurs
tables de la base de données.
Champ en double Un champ qui apparaît dans deux ou plusieurs tables pour
l'une des raisons suivantes : Il est utilisé pour relier un ensemble de tables

entre elles ; cela indiqueplusieurs occurrences d'un type particulier de

valeur ; ou il existe un besoin perçu d’informations supplémentaires.

Données dynamiques Données qui changent constamment et reflètent

toujours les informations les plus récentes.

Éléments d'une clé candidate Un ensemble de lignes directrices utilisées

pour déterminer si un champ donné est apte à servir de clé candidate.

Éléments d'une clé étrangère Un ensemble de directives utilisées pour

déterminer si un champ donné est apte à servir de clé étrangère.

Éléments d'une clé primaire Ensemble de lignes directrices utilisées pour

déterminer si un champ de clé candidat donné est apte à servir de clé primaire.

Éléments du champ idéal Un ensemble de lignes directrices utilisées pour

créer des structures de champ sonore et pour aider à identifier les champs mal

conçus.

Éléments de la table idéale Un ensemble de lignes directrices utilisées pour

créer des structures de table solides et pour aider à identifier les tables mal

conçues.

Utilisateur final Personne qui utilise et travaille avec une base de données ou
un programme d'application de base de données.

Application pour utilisateur final Logiciel commercial ou personnalisé

généralement hébergé sur un appareil personnel tel qu'un smartphone et

utilisé pour fournir une interface conviviale pour une base de données.
Application utilisateur final Logiciel commercial ou personnalisé
généralement hébergé sur un ordinateur ou une tablette et utilisé comme

interface conviviale vers une base de données.

Intégrité de l'entité Voir Intégrité au niveau de la table .

Événement Quelque chose qui se produit à un moment donné (comme un

rendez-vous chez le médecin ou une transaction boursière) et qui peut être

représenté par un tableau.

Informations explicites Informations clairement indiquées dans la réponse à

une question donnée.

Champ La plus petite structure de la base de données. Il représente une

caractéristique du sujet de la table à laquelle il appartient et constitue la seule

structure qui stocke réellement les données dans la base de données.

Intégrité au niveau du champ Ce type d'intégrité des données garantit ce

qui suit : L'identité et le but d'un champ sont clairs, et tous les tableaux dans

lesquels il apparaît sont correctement identifiés ; les définitions des champs

sont cohérentes dans toute la base de données ; les valeurs d'un champ sont

cohérentes et valides ; et les types de modifications, de comparaisons et

d'opérations pouvant être appliquées aux valeurs du champ sont clairement

identifiés.

Spécification de champ Représente tous les éléments généraux, physiques

et logiques d'un champ. (C'est ce qu'on appelle traditionnellement un

domaine.)

Règle métier spécifique au champ Règle qui impose des contraintes sur les
éléments d'une spécification de champ pour un champ donné.
Filtre Un ensemble d'une ou plusieurs contraintes imposées à une vue qui
l'amènent à renvoyer un ensemble spécifique d'informations.

Liste des tables finales Cette liste contient des informations clés (nom, type
et description) sur chaque table de la base de données.

Logique des prédicats du premier ordre Une des deux branches des
mathématiques sur lesquelles est basé le modèle relationnel.

Processus de mise en œuvre L'ensemble des actions requises pour

concevoir une base de données logique et l'incorporer dans un SGBDR

spécifique.

Informations implicites Informations qui ne sont pas expressément

indiquées dans une réponse à une question donnée ; vous devez le déduire de

votre examen de la réponse.

Index Structure au sein d'un programme SGBDR qui peut être utilisée pour
améliorer le traitement des données.

Informations Données traitées de manière à les rendre significatives et utiles

à la personne qui les utilise ou les consulte.

Exigences en matière d'informations Informations qui doivent être prises

en charge par les données de la base de données pour que l'organisation

fonctionne correctement, efficacement et efficacement.

Base de données héritée Voir Base de données héritée .

Clés Champs spéciaux qui jouent des rôles très spécifiques dans une table ; le
type de clé détermine son objectif dans le tableau. Les quatre principaux types

de clés sont candidats, primaires, alternatifs et étrangers.

Base de données héritée Base de données qui existe et est utilisée depuis
plusieurs années ou plus.

Table de liaison Table qui permet d'établir une relation plusieurs-à-plusieurs

entre une paire de tables donnée.

Liste des caractéristiques Une collection de noms qui impliquent divers

attributs des éléments de la liste des sujets.

Liste de sujets Une collection de noms qui représentent des sujets

susceptibles d'intéresser l'organisation.

Indépendance logique des données Les modifications apportées à la

conception logique de la base de données ne doivent pas nécessairement

affecter négativement les applications construites sur la base de données.

Table de recherche Voir Table de validation .

Ordinateur central Un grand ordinateur haut de gamme et extrêmement

puissant, conçu pour gérer littéralement des millions de calculs très intensifs

simultanément.

Relation plusieurs-à-plusieurs Relation entre une paire de tables dans une

base de données relationnelle dans laquelle un seul enregistrement de la

première table peut être lié à plusieurs enregistrements de la deuxième table,

et un seul enregistrement de la deuxième table peut être lié à plusieurs.

enregistrements dans le premier tableau.

Valeur manquante Une valeur de données qui n'a pas été saisie dans un
champ donné en raison d'une erreur humaine.
Objectif de la mission Une instruction qui représente une tâche générale
qu'un utilisateur effectuera sur les données de la base de données.

Énoncé de mission Un énoncé qui établit l'objectif de la base de données et

fournit une orientation distincte pour votre travail de conception.

Appareil mobile Un appareil informatique que vous pouvez facilement

transporter avec vous, comme un smartphone ou une tablette.

Intégrité multiniveau Cela intègre au moins deux des éléments suivants :

l'intégrité au niveau du champ, l'intégrité au niveau de la table, l'intégrité au

niveau des relations et les règles métier.

Champ en plusieurs parties Un champ qui contient plusieurs types de

valeurs distinctes.

Champ à valeurs multiples Un champ qui contient plusieurs instances du

même type de valeur.

Non-clé Un champ qui ne sert pas de clé candidate, primaire, alternative ou

étrangère.

Forme normale Un ensemble spécifique de règles qui peuvent être utilisées

pour tester une structure de table afin de garantir qu'elle est solide et exempte

de problèmes.

Normalisation Processus de décomposition de grandes tables en tables plus

petites pour éliminer les données redondantes et les données en double.

Null Il s'agit d'une condition qui représente une valeur manquante ou inconnue
; il ne représente pas un zéro ou une chaîne de texte composée d'un ou

plusieurs espaces vides.

Objet Un élément tangible (tel qu'une personne, un lieu ou une chose) qui
peut être représenté par un tableau.

OLAP (Online Analytical Processing) Méthode de présentation des données

d'une base de données analytique dans laquelle les données sont résumées et

présentées sous la forme d'un tableau ou d'un cube.

OLTP (Online Transaction Processing) Système permettant de traiter les

transactions dès que l'ordinateur les reçoit et de mettre à jour immédiatement

les fichiers maîtres dans un système de gestion de base de données.

Relation un-à-plusieurs Relation entre une paire de tables dans une base
de données relationnelle dans laquelle un seul enregistrement de la première

table peut être lié à plusieurs enregistrements de la deuxième table, mais un

seul enregistrement de la deuxième table ne peut être lié qu'à un

enregistrement dans la première table.

Relation un-à-un Relation entre une paire de tables dans une base de
données relationnelle dans laquelle un seul enregistrement de la première

table est lié à un seul enregistrement de la deuxième table, et un seul

enregistrement de la deuxième table est lié à un seul enregistrement.

enregistrer dans le premier tableau.

Traitement analytique en ligne Voir OLAP .

Traitement des transactions en ligne Voir OLTP .

Question ouverte Une question à laquelle on peut répondre de diverses

manières et qui peut conduire à d'autres questions de suivi.
Système d'exploitation Ensemble complet de logiciels requis pour gérer et
fournir des services pour le matériel informatique, les équipements

périphériques (tels que les imprimantes et les scanners) et tous les autres

logiciels. L'ordinateur ne peut pas fonctionner sans le système d'exploitation.

Base de données opérationnelle Un type de base de données qui stocke

des données dynamiques et est utilisée dans des situations où il existe un

besoin de collecter, de modifier et de maintenir des données

quotidiennement ; il est généralement associé à OLTP.

Base de données papier Une collection lâche de formulaires, de papiers, de

dossiers en papier, etc., utilisée pour collecter et conserver des données.

Table parent Au sein d'une relation donnée, table contenant des

enregistrements qui ne dépendent pas de l'existence d'enregistrements dans la

table associée.

Analyser Pour décomposer une valeur de données donnée en parties plus

petites et distinctes.

Indépendance physique des données Les modifications apportées par le

fournisseur du logiciel de base de données à la mise en œuvre physique de la

base de données n'affecteront pas négativement les applications construites

sur la base de données.

Liste de champs préliminaire Une liste de champs qui représente les

exigences fondamentales en matière de données de l'organisation et constitue

l'ensemble principal de champs qui doivent être définis dans la base de

données.

Liste de tables préliminaires Ensemble principal de tables qui doivent être

définies dans la base de données.
Clé primaire Champ ou groupe de champs qui identifie de manière unique
chaque enregistrement dans une table.

Environnement de programmation Combinaison d'une plate-forme

informatique donnée (ordinateur central, PC, client/serveur, cloud, etc.), d'un

système d'exploitation et d'un langage de programmation.

Langage de programmation Un logiciel qui peut être utilisé pour définir des
ensembles d'instructions qui seront finalement traitées et exécutées par

l'ordinateur.

Requête Une demande d'informations posée à la base de données via une

instruction de requête SQL.

Query Builder Un outil au sein d'un logiciel de base de données qui permet à
un utilisateur de créer une requête via une interface graphique facile à utiliser.

RDBMS (Relational Database Management System) Un logiciel utilisé

pour créer, maintenir, modifier et manipuler une base de données relationnelle.

Enregistrement Structure composée d'un ensemble complet de valeurs

singulières (qu'elles soient nulles ou non) pour chaque champ d'une table et

représentant une instance unique du sujet de la table.

Relation récursive Voir Relation d'auto-référencement .

Données redondantes Valeur répétée dans un champ en raison de la

participation du champ à la mise en relation de deux tables ou en raison d'une

anomalie dans un champ ou une table.

Champ de référence Voir Champ en double .

Intégrité référentielle Voir Intégrité au niveau relationnel .

Relation L'équivalent d'une table dans le modèle relationnel.

Base de données relationnelle Type de base de données qui stocke les

données dans des relations (perçues par l'utilisateur sous forme de

tables). Chaque relation est composée de tuples (enregistrements) et

d'attributs (champs).

Système de gestion de base de données relationnelle Voir SGBDR .

Modèle relationnel Un modèle de données basé sur la théorie des ensembles

et la logique des prédicats de premier ordre inventée par le Dr Edgar F. Codd.

Relation Interdépendance qui existe entre deux tables lorsque les

enregistrements de la première table peuvent d'une manière ou d'une autre

être associés aux enregistrements de la seconde table. Les trois types de

relations dans une base de données relationnelle sont un à un, un à plusieurs

et plusieurs à plusieurs.

Diagramme de relation Représentation graphique de la relation entre une

paire de tables donnée ou entre un ensemble donné d'enregistrements au sein

d'une table.

Intégrité au niveau des relations Type d'intégrité des données qui garantit
que la relation entre une paire de tables est solide et que les enregistrements

des tables sont synchronisés chaque fois que des données sont saisies, mises à

jour ou supprimées de l'une ou l'autre des tables.

Règle métier spécifique à la relation Règle qui impose des contraintes qui
affectent les caractéristiques d'une relation.
Rapport Tout document manuscrit, dactylographié ou généré par ordinateur
utilisé pour organiser et présenter des données de manière à ce qu'elles soient

significatives pour la ou les personnes qui les consultent.

Présentation par écran Une série d'écrans qui traitent de divers sujets de
manière organisée.

Relation plusieurs-à-plusieurs auto-référencée Une relation qui existe

lorsqu'un enregistrement donné dans une table peut être lié à un ou plusieurs

autres enregistrements dans la table et qu'un ou plusieurs enregistrements

peuvent eux-mêmes être liés à l'enregistrement donné.

Relation un-à-plusieurs auto-référencée Relation qui existe lorsqu'un

enregistrement donné dans une table peut être lié à un ou plusieurs autres

enregistrements dans la table.

Relation un-à-un auto-référencée Relation qui existe lorsqu'un

enregistrement donné dans une table peut être lié à un seul autre

enregistrement dans la table.

Relation d'auto-référencement Relation qui existe entre les

enregistrements d'une table. Semblable à son homologue à table double, une

relation d'auto-référencement peut être un-à-un, un-à-plusieurs ou plusieurs-à-

plusieurs.

Théorie des ensembles Une des deux branches des mathématiques sur
lesquelles est basé le modèle relationnel.

SQL (Structured Query Language) Langage standardisé utilisé pour créer,

maintenir, modifier et interroger des bases de données relationnelles.

Données statiques Données qui ne sont jamais (ou très rarement) modifiées.
Intégrité structurelle Un ensemble de règles ou de directives qui régissent la
manière dont les champs, les tables et les vues sont définis.

Langage de requête structuré Voir SQL .

Table de sous-ensemble Table qui représente un sujet subordonné d'une

table de données particulière.

Table La structure principale d'une base de données. Il est composé de

champs et d'enregistrements et représente toujours un sujet unique et

spécifique.

Description du tableau Une déclaration qui fournit une définition claire du

sujet représenté par le tableau et indique pourquoi le sujet est important pour

l'organisation.

Intégrité au niveau de la table Ce type d'intégrité des données garantit

qu'une table est exempte d'enregistrements en double et que les valeurs de la

clé primaire de la table sont uniques, ne sont jamais nulles et identifient

exclusivement les enregistrements de la table.

Tuple L'équivalent d'un enregistrement dans le modèle relationnel.

Type de participation La manière dont une table participe à une relation

donnée dans une base de données relationnelle. Le type de participation peut

être obligatoire ou facultatif.

Type de relation La manière dont une paire de tables donnée peut être liée
(un à un, un à plusieurs, plusieurs à plusieurs).

Valeur inconnue Une valeur pour un champ spécifique qui n'a pas encore été
déterminée ou définie.
URL Acronyme de Uniform Resource Locator. Il représente une adresse pour
une ressource donnée sur Internet, telle que www.ForMereMortals.com .

Table de validation Table qui stocke les données spécifiquement utilisées

pour mettre en œuvre l'intégrité des données. (Ceci est également connu sous

le nom de table de recherche.)

Vue de validation Une vue utilisée spécifiquement pour implémenter

l'intégrité des données.

Afficher Une table virtuelle composée de champs provenant d'une ou plusieurs

tables de base dans la base de données.

Spécification de la vue Représente toutes les caractéristiques d'une vue,

telles que le nom, le type, les tables de base, etc.

Page Web Un document composé d'un fichier HTML (Hypertext Markup

Language) et des fichiers de support associés accessibles via Internet.

Chaîne de longueur nulle Deux guillemets simples consécutifs sans espace

entre eux.

rtd
qP
ouae
sercb
uahl
em
èr
tcd
rhe
es
s
m
a
t
i
è
r
e
s