les bases de données relationnellesekhalid.magix.net/public/bd/modelerelationel.pdf · les bases...

of 27 /27
Les bases de données relationnelles, normalisation et SQL Page 1 Conférence Borland 4/5 nov 97 - Conférence DL210 + Sept 98 Version 20/07/2000 02:51 © O.Dahan Les Bases de Données Relationnelles : Normalisation et SQL Email : [email protected] Web : http://perso.cybercable.fr/stargate/ 1. Introduction Depuis sa première version 16 bits, jusqu'à la version 32 bits actuelle (V4), Delphi est livré avec un moteur de base de données de type Relationnel : le BDE 1 . Les grandes fonctions de ce moteur sont accessibles via des composants Delphi, ce qui en cache la sophistication mais aussi le fonctionnement intime. La banalisation bénéfique des composants fait que, visuellement depuis la palette, un TTable occupe une place ni plus ni moins importante qu’un TLabel. Pourtant l’un est une porte d’entrée vers le BDE et l’autre n’est qu’un bout de texte affiché à l’écran. Les SGBD-R, avec leur généralisation en microinformatique, marquent une étape essentielle de l’évolution du développement d’applications pour PC, il est donc important, afin de concevoir des logiciels performants, de connaître les principes et concepts sous-jacents de cette technologie. Le but du présent article est de rappeler ces principes et concepts. Il se termine par une présentation du SQL 2 au travers de Delphi. 2. SGBD-R 2.1 Le BDE, bref historique Un moteur de base de données relationnel est avant tout un logiciel comme un autre. Sa fonction principale est de stocker de l’information et de la restituer en établissant un dialogue avec l’application cliente. Ce dialogue repose sur un langage, généralement SQL, dont nous verrons plus loin la nature. Le BDE est un SGBD-R. Il a été originellement conçu pour gérer le format de données Paradox 3 . A ce titre il privilégie, en interne, un autre langage d’interrogation qui est le QBE 4 . Dans ses premières versions l’ancêtre du BDE était un logiciel DOS dit « résidant » avec lequel le développeur dialoguait par des Interruptions 5 . Après le rachat de dBase, Borland a entrepris de fusionner les méthodes d’exploitation des données de ce produit et de celles de Paradox. Puis, au fil des évolutions, le BDE a pris corps, notamment en devenant une interface de programmation unifiée donnant accès à d’autres moteurs de base de données. Le support du SQL local a aussi été ajouté, en plus du QBE. C’est ainsi que le BDE s’est aussi ouvert aux données gérées via ODBC de Microsoft et aux principaux grands SGBD-R du marché via des pilotes spécialisés et optimisés que sont les SQL Links. Aujourd’hui, sous Windows, le BDE se présente sous la forme d’une série de DLL proposant une interface de programmation (API 6 ) qui a été encapsulée dans Delphi sous la forme de composants 7 . 2.2 Concepts fondateurs des SGBD-R 2.2.1 Définitions Les SGBD-R utilisent une terminologie propre dont voici un extrait : Champ Plus petit élément insécable d’information. Il peut être aussi petit qu’un Bit ou aussi grand qu’une image. Le contenu d’un champ ne peut être découpé en sous-unités plus petites sans perte de sens de l’information. Un champ 1 BDE : Borland Database Engine, Moteur de Base de Données Borland 2 SQL : Strutured Query Language, Langage d’Interrogation Structuré 3 Originellement créé par ANSA Software puis acheté par Borland, aujourd’hui vendu par Corell sous Licence Borland. 4 QBE : Query By Example, Requête par l’exemple. 5 Technique de programmation utilisant des adresses mémoire, points d’entrée, permettant un dialogue entre une application cliente (appelante) et une librairie de fonction (serveur). Le DOS se programmait de cette façon ainsi que tous les modules chargés en mémoire appelés « résidants ». 6 API : Application Program Interface, interface de programmation. 7 Composant : Objet répondant à une syntaxe particulière lui permettant d’être ajouté à la palette de Delphi.

Author: lynguyet

Post on 10-Sep-2018

217 views

Category:

Documents


0 download

Embed Size (px)

TRANSCRIPT

  • Les bases de donnes relationnelles, normalisation et SQL Page 1

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Les Bases de Donnes Relationnelles : Normalisation et SQL Email : [email protected]

    Web : http://perso.cybercable.fr/stargate/

    1. Introduction Depuis sa premire version 16 bits, jusqu' la version 32 bits actuelle (V4), Delphi est livr avec un moteur de base de donnes de type Relationnel : le BDE1. Les grandes fonctions de ce moteur sont accessibles via des composants Delphi, ce qui en cache la sophistication mais aussi le fonctionnement intime. La banalisation bnfique des composants fait que, visuellement depuis la palette, un TTable occupe une place ni plus ni moins importante quun TLabel. Pourtant lun est une porte dentre vers le BDE et lautre nest quun bout de texte affich lcran. Les SGBD-R, avec leur gnralisation en microinformatique, marquent une tape essentielle de lvolution du dveloppement dapplications pour PC, il est donc important, afin de concevoir des logiciels performants, de connatre les principes et concepts sous-jacents de cette technologie. Le but du prsent article est de rappeler ces principes et concepts. Il se termine par une prsentation du SQL2 au travers de Delphi.

    2. SGBD-R

    2.1 Le BDE, bref historique Un moteur de base de donnes relationnel est avant tout un logiciel comme un autre. Sa fonction principale est de stocker de linformation et de la restituer en tablissant un dialogue avec lapplication cliente. Ce dialogue repose sur un langage, gnralement SQL, dont nous verrons plus loin la nature. Le BDE est un SGBD-R. Il a t originellement conu pour grer le format de donnes Paradox3. A ce titre il privilgie, en interne, un autre langage dinterrogation qui est le QBE4. Dans ses premires versions lanctre du BDE tait un logiciel DOS dit rsidant avec lequel le dveloppeur dialoguait par des Interruptions5. Aprs le rachat de dBase, Borland a entrepris de fusionner les mthodes dexploitation des donnes de ce produit et de celles de Paradox. Puis, au fil des volutions, le BDE a pris corps, notamment en devenant une interface de programmation unifie donnant accs dautres moteurs de base de donnes. Le support du SQL local a aussi t ajout, en plus du QBE. Cest ainsi que le BDE sest aussi ouvert aux donnes gres via ODBC de Microsoft et aux principaux grands SGBD-R du march via des pilotes spcialiss et optimiss que sont les SQL Links. Aujourdhui, sous Windows, le BDE se prsente sous la forme dune srie de DLL proposant une interface de programmation (API6) qui a t encapsule dans Delphi sous la forme de composants7.

    2.2 Concepts fondateurs des SGBD-R

    2.2.1 Dfinitions

    Les SGBD-R utilisent une terminologie propre dont voici un extrait : Champ Plus petit lment inscable dinformation. Il peut tre aussi petit quun Bit

    ou aussi grand quune image. Le contenu dun champ ne peut tre dcoup en sous-units plus petites sans perte de sens de linformation. Un champ

    1 BDE : Borland Database Engine, Moteur de Base de Donnes Borland 2 SQL : Strutured Query Language, Langage dInterrogation Structur 3 Originellement cr par ANSA Software puis achet par Borland, aujourdhui vendu par Corell sous Licence Borland. 4 QBE : Query By Example, Requte par lexemple. 5 Technique de programmation utilisant des adresses mmoire, points dentre, permettant un dialogue entre une application cliente (appelante) et une librairie de fonction (serveur). Le DOS se programmait de cette faon ainsi que tous les modules chargs en mmoire appels rsidants . 6 API : Application Program Interface, interface de programmation. 7 Composant : Objet rpondant une syntaxe particulire lui permettant dtre ajout la palette de Delphi.

  • Les bases de donnes relationnelles, normalisation et SQL Page 2

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    ne peut avoir quune seule signification constante dans le temps. Enregistrement Collection de champs dont lunit repose sur une ou plusieurs relations. Si

    on imagine un fichier de donnes sous la forme dun tableau, les champs sont les colonnes, les enregistrements les lignes.

    Table Collection denregistrements ayant la mme structure (mme dcoupage de champs). Souvent confondu avec un fichier, le concept de table est pourtant radicalement diffrent notamment par le fait quil peut fort bien ny avoir aucun fichier reprsentant physiquement les donnes dune table. De plus, le concept de table impose une structure (au moins logique) alors quun fichier peut contenir nimporte quoi, stock nimporte comment.

    Base de donnes Collection de tables. Une base de donnes peut tre aussi bien un sous-rpertoire sur un disque (comme pour dBase ou Paradox) quune seule et mme entit gre par un Serveur local ou distant (Interbase, Oracle...).

    Cl primaire Un champ ou un ensemble de champs permettant didentifier sans ambigut tout enregistrement dune table. Par essence les cls primaires sont uniques (elles nacceptent pas les doublons).

    Cl trangre Un champ ou un ensemble de champs lintrieur dune table qui se trouvent tre la cl primaire dune autre table.

    Cl secondaire Une table peu possder, en plus de sa cl primaire, dautres cls dites secondaires. Elles sont concrtises par des index (secondaires eux aussi). Les cls secondaires se caractrisent par le fait que pour tre cls elles sont uniques ( la diffrence dun simple champ dindex secondaire). Les cls secondaires ont un intrt pratique mais ne font pas directement partie de la thorie relationnelle.

    2.2.2 Le Relationnel

    La caractristique la plus marquante des SGBD-R ... cest le R ... En effet, lvolution majeure se trouve justement dans la capacit de ces systmes grer des relations entre des entits et de maintenir lintgrit de ces relations. Dans une gestion de fichier classique, de type squentiel index, cest le dveloppeur qui soccupe de tout. Lorsquil veut interroger les donnes, il doit crire une boucle pour balayer un ou plusieurs fichiers, parfois par une indirection depuis un ou plusieurs index, afin de trouver les donnes intressantes et les fournir dans un ordre prcis. Une telle programmation est incontournable puisque dans un tel cas il nexiste aucune intelligence sur laquelle le dveloppeur puisse se reposer pour le soulager. Les SGBD-R sont, comme nous le disions plus haut, des logiciels part entire, ds lors ils proposent une certaine puissance, une intelligence qui prend en charge certains aspects essentiels de la gestion des donnes. De plus, un SGBD-R connat les donnes quil gre : leur structure, les relations entre les champs et les tables. De fait, il est capable dautomatiser toutes les tches de bas niveau (maintenir les index, grer les conflits daccs, autoriser les annulations de modification, etc) mais aussi dassurer des fonctions de plus haut niveau comme la mise jour par lot denregistrements rpondant des critres ventuellement complexes ou ltablissements de rsultats synthtiques utilisant des calculs statistiques et des regroupements (par exemple le CA total et moyen par famille darticles et par reprsentant sur une priode donne). Un SGBD-R ne devine rien, il exploite les informations que le dveloppeur lui a donnes. Cest lors de la conception mme de la base de donnes que les relations entre les entits seront mises en vidence. La modlisation dune base de donnes relationnel passe par une phase de conception durant laquelle on peut utiliser des outils CASE qui en simplifient la mise en uvre, comme, par exemple, AMC Designor ou Win-Design.

    2.2.3 Les types de relations

    Dans un modle relationnel, on distingue plusieurs types de relations entre les entits. Lors du passage du modle conceptuel8 (logique) au modle Physique9 ces relations seront reprsentes soit par

    8 Le modle conceptuel reprsente toutes les relations existantes entre les entits. Par exemple, il peut y avoir un entit Client et une entit Commande entre lesquelles il existe une relation Un-vers-N.

  • Les bases de donnes relationnelles, normalisation et SQL Page 3

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    linsertion de cl trangres dans certaines tables, soit par la cration de nouvelles tables. Voici les relations utilises en pratique :

    2.2.3.1 Relation Un-vers-Un Une relation Un-vers-Un existe quand pour chaque cl primaire il y a zro ou une valeur correspondante pour un autre champ ou un autre enregistrement. Lorsque la relation concerne des champs, ceux-ci sont gnralement placs dans une mme table, mais cela nest pas obligatoire. Lorsque la relation concerne des entits (des enregistrements dans le modle physique) elle peut sentendre entre deux entits ou bien dune entit vers elle-mme. Ce dernier cas permet la reprsentation de hirarchies10 (par exemple lentit employ peut avoir une relation vers une autre entit employ avec la dfinition a pour chef... ).

    2.2.3.2 Relation Un-vers-N Une relation Un-vers-N (un vers plusieurs) existe quand, pour chaque enregistrement dans une table il existe zro ou plusieurs enregistrements lis dans une autre table (exemple : un client a plusieurs commandes).

    2.2.3.3 Relation N-vers-Un Une telle relation existe lorsque plusieurs enregistrements dune mme table font rfrence de faon non ambigu un seul enregistrement dune autre table. On appelle parfois cette relation une relation Lookup ou table de rfrence car elle reprsente une rfrence vers la cl primaire dune autre table. Une relation N-vers-Un impliquant des cls trangres peut gnralement tre renverse (en Un-vers-N), alors quune relation Un-vers-N impliquant que des cls primaires (liens identifiants) ne peut pas tre renverse en N-vers-Un.

    2.2.3.4 Relation N-vers-N Une telle relation existe lorsque plusieurs enregistrements dune mme table sont lis plusieurs autres enregistrements dune autre table. Cette relation est rversible par essence. Un exemple classique est celui des commandes et des articles : plusieurs commandes peuvent faire rfrences au mme article, et plusieurs articles peut tre utiliss dans une mme commande. Les bases de donnes relationnelles ne peuvent reprsenter directement les relations N-vers-N, le concepteur de la base doit crer une table intermdiaire (contenant des couples forms des cls primaires des deux tables en relation plus dventuelles proprits spcifiques la relation). Si on utilise un outil de type AMC Designor ou Win-Design, cest cet outil qui lors de la traduction du modle logique en modle physique fera apparatre la table intermdiaire automatiquement. Nous verrons un tel exemple plus loin.

    2.3 Les 12 Rgles dintgrit de Codd Cette introduction sur les SGBD-R ne serait pas complte sans lnonc des principes fondateurs de la thorie sous-jacente, celle du modle relationnel. Lorsque le Dr Codd dfinit le modle relationnel en 1970, construction qui sera reprise en suite par de nombreux auteurs, il nona un ensemble de 12 rgles pour la reprsentation des relations en table. Cet ensemble de rgles permet de mieux comprendre le cadre dans lequel a t conu le modle relationnel ainsi que la majorit des particularit du SQL. Et comprendre sur quoi on travaille est toujours un avantage un moment ou un autre...

    2.3.1 Rgle 0

    Pour quun systme de gestion de donnes soit considr comme une base de donne relationnelle, il doit utiliser exclusivement les relations pour grer la base de donnes.

    2.3.2 Rgle 1 - Rgle dinformation

    Toutes les informations de la base de donnes doivent tre reprsentes dune seule et mme manire, notamment par des valeurs dans les colonnes lintrieur de lignes.

    9 Le modle physique est la concrtisation du modle logique une fois la base cible choisie. Les entits deviennent des tables, les proprits deviennent des champs dans les tables, et on voit apparatre les cls trangres ainsi que les tables donnant corps certaines relations multiples. 10 Un tel bouclage dune table sur elle-mme sappelle aussi une auto-jointure

  • Les bases de donnes relationnelles, normalisation et SQL Page 4

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    2.3.3 Rgle 2 - Rgle de garantie daccs

    Chaque information stocke dans une base de donnes relationnelle doit pouvoir tre accessible en prcisant uniquement le nom de la table, le nom de la colonne et la valeur de la cl primaire.

    2.3.4 Rgle 3 - Rgle des informations manquantes

    Il doit y avoir un moyen dexprimer des valeurs manquantes dans la base de donnes dune faon homogne non dpendante du type de donne, expression qui doit tre supporte dans les oprations logiques. La rgle originale prcise quil faut diffrencier valeur manquante et valeur inapplicable, lheure actuelle les SGBD-R ne proposent majoritairement que le NULL.

    2.3.5 Rgle 4 - Catalogue systme

    La description de la base au niveau logique doit tre reprsente dynamiquement par un ensemble de donnes normalis de telle sorte que ce catalogue soit accessible aux utilisateurs autoriss depuis leur langage de requte. On voit ici que les formats dBase et Paradox ne satisfont pas cette exigence alors que Interbase ou tout autre serveur SQL ne saurait fonctionner sans tables systme. Ces pour cela quon choisira les seconds si on doit grer beaucoup dintgrit rfrentielle ou de contraintes.

    2.3.6 Rgle 5 - Rgle de sous-langage

    Le systme doit mettre la disposition au moins un langage relationnel qui : (1) a une syntaxe linaire, (2) peut tre utilis la fois de manire interactive et dans des programmes dapplication, et (3) supporte les oprations de dfinition de donnes (dont les vues), celles de manipulation de donnes (mise jour et accs), les contraintes de scurit et dintgrit, ainsi que les oprations de pilotage de transactions (dbut, validation, annulation). Le langage SQL propose tout cela.

    2.3.7 Rgle 6 - Rgle de mise jour des vues

    Le systme doit supporter la dfinition des vues et les informations des tables sous-jacentes doivent pouvoir tre mises jour directement depuis la vue. Les vues modifiables ne sont pas gres de la mme faon par tous les serveurs, et les vues, mme non modifiables nexistent pas en dBase et Paradox.

    2.3.8 Rgle 7 - Insertion, mise jour et suppression

    Le systme doit permettre aux oprateurs INSERT, UPDATE et DELETE dtre actifs en mme temps. Le SQL standard supporte cette contrainte.

    2.3.9 Rgle 8 - Indpendance des donnes physiques

    Les programmes dapplication et les oprations interactives ne doivent pas avoir tre modifis si la structure physique de la base est modifie. En ce sens SQL est un langage beaucoup plus portable que la majorit des langages classiques. Delphi et le BDE autorise dailleurs une trs bonne isolation entre reprsentation physique de la base et application. On peut ce sujet tudier lexemple fourni avec Delphi (MASTAPP) qui fonctionne aussi bien avec des donnes Paradox que sous Interbase.

    2.3.10 Rgle 9 - Indpendance des donnes logiques

    Les programmes dapplication et les oprations interactives nont pas tre modifis si la base de donnes est restructure, du moins tant quil ny a pas de perte dinformation.

    2.3.11 Rgle 10 - Indpendance par rapport aux contraintes dintgrit

    Les contraintes dintgrit doivent tre spcifies sparment des programmes dapplication et ranges dans le catalogue. On doit pouvoir les modifier comme on le souhaite, sans avoir toucher aux applications existantes.

    2.3.12 Rgle 11 - Indpendance par rapport la distribution des donnes

    Les applications existantes se drouleront normalement (1) quand une version distribue du SGBD est introduite pour la premire fois et (2) quand les donnes distribues sont redistribues dans le systme. Les versions distribues de SQL commencent tout juste apparatre et il est difficile aujourdhui de donner des exemples prcis de respect de cette rgle.

    2.3.13 Rgle 12 - Rgle de non-subversion

    Si le systme dispose dune interface de bas niveau (traitement dun enregistrement la fois), celle-ci na pas la possibilit de pervertir le systme, cest dire de passer outre une directive de scurit relationnelle ou une contrainte dintgrit. SQL-92 rpond ces conditions.

  • Les bases de donnes relationnelles, normalisation et SQL Page 5

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    3. La normalisation

    3.1 But et Principe Il y a plusieurs bonnes raisons de normaliser une base de donnes, la premire relve uniquement du bon sens : Le BDE, et tous les serveurs SQL, ont t conus sur la base de lhypothse que les bases quils auraient a traiter seraient normalises. De ce fait, ces SGBD-R sont plus efficaces lorsque la base utilise est normalise. Cela peut paratre une vidence, mais tout va mieux lorsquon le dit... Parmi les raisons plus spcifiquement lies au relationnel, la normalisation apporte : des requtes plus simples crire11, des donnes plus facilement accessibles ; une meilleure intgrit des donnes ; la diminution des erreurs lors de linsertion ou de la suppression de nouvelles donnes et une utilisation optimale des ressources. Il faut tout de mme prciser que la normalisation des bases de donnes nest pas une fin en soi, seulement un outil pratique et performant et que chaque concepteur de base de donnes doit dcider si, dans un cas prcis, la normalisation est la solution la plus efficace. La dnormalisation est une opration parfois ncessaire, toutefois il faut bien lentendre dans le sens que son nom indique : la suppression dune normalisation existante... Il est donc toujours prfrable, au niveau conceptuel, de commencer par concevoir une base de donnes normalise. Ensuite, et seulement ensuite, on peut dnormaliser en justifiant et en assumant chaque opration ponctuelle de ce type.

    3.2 Dpendances fonctionnelles et dpendances de plusieurs valeurs Une forme normale (que nous aborderons la section suivante) est une mthode de classification de table qui repose sur les dpendances fonctionnelles (DF) quelle comprend. Une dpendance fonctionnelle signifie que si lon connat la valeur dun attribut on peut toujours dterminer la valeur dun autre attribut. La notation utilise dans la thorie relationnelle est une flche entre les deux attributs, par exemple A B snonce A dtermine B . Si on connat votre numro de salari dans lentreprise on peut trouver votre nom. La dpendance de plusieurs valeurs (DPV) signifie que si lon connat la valeur dun attribut on peut toujours dterminer les valeurs dun ensemble dautres attributs. La notation retenue dans la thorie relationnelle est une flche double pointe entre les deux attributs, par exemple A B snonce A dtermine plusieurs B . Si on connat le nom dun professeur on peut dterminer la liste de ses tudiants. La comprhension des DF et les DPV joue un rle essentiel dans celle des formes normales.

    3.3 Les Formes Normales Normaliser une base consiste appliquer des rgles regroupes sous la dnomination de Formes normales12 . Ces rgles sont aussi utilises, dans lautre sens, pour valider ltat de normalisation dune base Les formes normales sous entendent que chaque table possde une cl primaire. Chaque forme porte un numro dordre (ou un acronyme). Les voici :

    3.3.1 Premire forme normale (1NF)

    Il sagit de la premire rgle quon pourrait dire fondatrice. Elle fait partie de la dfinition formelle des bases de donnes relationnelles. Cette rgle stipule que les champs de chaque table doivent tre atomiques et quil ne peut exister de champs rptitifs. De plus, chaque champ doit avoir une signification prcise constante dans le temps.

    11 Mais pas forcment plus courtes ! 12 Normal Form en anglais, not NF prcd du numro de la forme comme 1NF pour la 1re forme normale.

  • Les bases de donnes relationnelles, normalisation et SQL Page 6

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Nom Adresse Ville Jean Durand 21 rue des quarks Paris, 75 Liliane Faure 45 avenue Pasteur Crteil, 94 Olivier Sautet 123 bis rue Lavoisier Versailles, 78

    Tableau 1 - Atomicit des champs, 1re forme, exemple 1

    VOIR LA TABLE EXEMPLE TABLE1.DB Pourquoi cette table nest-elle pas conforme la 1re forme normale ? La raison principale est que les champs ne sont pas tous atomiques. Par exemple le champ Nom contient la fois nom et prnom, il est possible de dcouper ce champ sans faire perdre de sens linformation, ce qui en faciliterait mme laccs et le tri. De la mme faon, le champ ville intgre le numro de dpartement, ce qui nest pas trs pratique si on dsire sortir, par exemple, la liste de toutes les personnes du Val de Marne. Dans un tel cas il faudra analyser chaque enregistrement en esprant que la saisie est homogne (que la virgule est toujours prsente, quil ny a pas de caractres non valides, etc). En fait, pour faire que cette table rponde la 1re forme normale, il faudra la restructurer pour quelle ressemble celle-ci : Nom Prnom Adresse Ville Dpartement Durand Jean 21 rue des quarks Paris 75 Faure Liliane 45 avenue Pasteur Crteil 94 Sautet Olivier 123 bis rue Lavoisier Versailles 78

    Tableau 2 - Atomicit des champs, 1re forme, exemple 1 corrig

    VOIR TABLE : TABLE1 CORRIGEE.DB Maintenant que tous les champs sont atomiques, les tris et les recherches deviennent plus simples, plus directs. Certaines personnes prconisent de dcouper aussi ladresse en numro de rue, rue, etc... En fait il existe une norme ISO des adresses quon est libre dutiliser ou non. La varit des types de voies, des bourgades et autres lieux-dits rend un tel dcoupage lourd et peu adapt la majorit des applications de gestion. Il ne nous a jamais t donn de voir un cadre dapplication dans lequel une telle opration avait une raison fonctionnelle, mais cela existe. Regardons maintenant ce second exemple : Numro_Emprunteur Livre_1 Livre_2 Livre_3 150001 James Bond et Dr No Mobby Dick 150002 Alice au pays... Colargol Tintin et le Lotus bleu 150009 La Relativit

    Tableau 3 - Champs rptitifs - 1re forme - Exemple 2

    VOIR TABLE TABLE2.DB En quoi cette table ne rpond-t-elle pas la 1re forme normale ? La rponse se trouve dans la liste des livres. En effet, la 1re forme normale stipule que les champs ne peuvent pas tre rptitifs. De fait, on comprend que chercher qui a emprunt Tintin et le Lotus bleu obligera balayer chaque enregistrement puis rechercher la prsence de ce titre dans chacune des trois colonnes. Comme dans le 1er exemple, il faudra esprer que la saisie est homogne et que ce titre aura bien t tap de la mme faon que celui quon recherche, le moindre espace de trop fera chouer la recherche... Plus loin, si demain il faut grer 4 livres au lieu de trois cela impliquera la fois une modification de la table (intervention dun spcialiste sur chaque site ou cration dun logiciel de mise jour quil faudra tester et packager) et une refonte de toutes les squences de recherche qui rclameront une fois encore

  • Les bases de donnes relationnelles, normalisation et SQL Page 7

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    des tests ainsi que la fourniture dune mise jour du logiciel chaque site utilisateur. Autant de dpenses qui peuvent tre trs lourdes, uniquement pour avoir ngliger de normaliser la base de donnes... On voit ici que lintrt de cette dmarche va bien au-del de la satisfaction intellectuelle. Afin de rendre la table conforme la 1re forme normale il nous faudra la scinder au minimum en deux autres tables, voire en trois. Le choix repose ici sur les cardinalits13 de la relation. Sagissant de livres et sil nexiste quun exemplaire de chaque titre, il ne pourra sagir, entre les emprunteurs et les livres que dune relation Un-vers-N car une mme personne peut emprunter plusieurs livres alors quun livre ne peut tre emprunt que par une seule personne la fois. Sil sagissait non plus demprunteurs et de livres mais dlves affects des cours, la relation serait de type N-vers-N, un lve pouvant suivre plusieurs cours et un mme cours pouvant recevoir plusieurs lves (dans ce cas trois tables seraient ncessaires). Ce cas pourrait tre aussi celui des livres sil existe plusieurs exemplaires des mmes titres. Dans notre exemple, la normalisation nous fera crer deux tables qui ressembleront : Numro_Emprunteur Nom_Emprunteur 150001 Durand 150002 Leroux 150003 Martinet

    Tableau 4 - 1re forme - Exemple 2 corrig - 1/2

    Livre Emprunt_Par Alice au pays des merveilles 150002 Colargol 150002 James Bond et Dr No 150001 Mobby Dick 150001 Relativit (la) 150003 Tintin et le Lotus bleu 150002

    Tableau 5 - 1re forme - Exemple 2 corrig - 2/2

    VOIR TABLES TABLE2C1.DB ET TABLE2C2.DB Sous cette nouvelle forme on voit quil est fort simple de savoir immdiatement qui a emprunt quel livre ou de connatre la liste des livres emprunts par une personne. Dans le premier cas il suffira de lire le code Emprunteur dans la table des livres puis daccder lenregistrement de celui-ci pour en connatre le dtail. Dans le second cas il suffira de balayer la colonne des codes emprunteurs de la table des livres pour connatre tous les livres emprunts par une mme personne. En fait, de telles oprations sur une base de donnes normalise seffectuent de faon fort simple laide du SQL. Il faut noter quon suppose quici le champ Numro_Emprunteur est la cl primaire de la table des emprunteurs et que le champ Livre est la cl primaire de la table des livres. De ce fait, le champ Emprunt_par de la table des livres est une cl trangre. Dun point de vue conceptuel, le MCD14 ressemblera :

    13 Les cardinalit dune relation sont les nombres qui caractrisent le type de relation discuts la section 2.2.3 Les types de relations. 14 MCD : Modle Conceptuel des Donnes

  • Les bases de donnes relationnelles, normalisation et SQL Page 8

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    1,1

    0,n

    EmprunteurCode_EmprunteurNom

    LivresTitre

    Emprunte zro ou plusieurs

    Figure 1 - 1re forme - MCD exemple 2

    La traduction de ce modle conceptuel en MPD15 ressemblera :

    EMPRUNTEURSCODE_EMPRUNTEURNOM

    LIVRESTITRECODE_EMPRUNTEUR

    Figure 2 - 1re forme - MPD exemple 2

    Continuons notre exploration des violations de la 1re forme normale... et dites ce que vous pensez de la table suivante (suivi de production dune ferme): Animal Date Quantit Poule10 08/01/1997 2 Vache07 08/01/1997 5 Poule09 08/01/1997 1 Vache04 08/01/1997 10 Vache12 08/01/1997 9

    Tableau 6 - 1re forme - Exemple 3

    A premire vue tous les champs sont atomiques. Il nexiste pas de champs rptitifs... et pourtant... Il sera trs difficile de faire des statistiques de production par jour, par exemple, car le champ Quantit reprsente une fois un nombre dufs, et dautres fois des litres de lait. En programmation structure, si on exploite les enregistrements avec variantes on peut trs bien se satisfaire dune stockage de ce type qui aura, dans un tel cadre, lavantage dtre compact (un seul fichier). Toutefois cet avantage na plus de sens dans le contexte des SGBD-R, et, au contraire, il interdit de se servir des ordres SQL qui permettront dobtenir sans programmation relle des rsultats qui ncessitaient, avant, des algorithmes spcifiques. Ainsi, dans lexemple ci-dessus, le champ Quantit na pas une signification prcise constante dans le temps.Cest une violation de la 1NF. Il faudra restructurer les donnes. A ce stade il ne peut y avoir de recette automatique tout dpendra des utilisations qui seront faites des donnes. Une version simple consistera crer deux tables, une pour les poules, lautre pour les vaches. Toutefois on voit facilement les limites dune telle logique, notamment dans le cas o il faut grer dautres types de production (incubateurs dbouchant sur des naissances de n poussins, parcelles de vignes donnant n litres de jus de raisin, etc).

    15 MPD : Modle Physique des Donnes

  • Les bases de donnes relationnelles, normalisation et SQL Page 9

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Dans le cadre dune utilisation simple ou pourra mme ici lever lambigut du champ Quantit en ajoutant un champ Unit qui fera rfrence une table des units qui, ce stade ne contiendra que deux enregistrements litre et uf . Toutefois seule la version deux tables distinctes est rellement conforme 1NF. LES TABLES TABLE3C1.DB ET TABLE3C2.DB MONTRENT UNE SOLUTION

    3.3.2 Seconde forme normale (2NF)

    Le respect de la seconde forme normale est aussi dune grande importante. La dfinition qui suit vous semblera peut-tre trop formelle, mais les exemples vous prouveront quici aussi il ne sagit que de bon sens. Une relation respecte la seconde forme normale lorsque toutes ses proprits non-cl sont totalement dpendantes fonctionnellement de la totalit de la cl primaire. Si X et Y sont des colonnes et que X est une cl, alors pour tout Z qui est un sous-ensemble de X, il ne peut y avoir Z Y. Considrons la table suivante : NumSalari Nom NumProjet Heures 20036 Durand 1 18,5 20036 Durand 2 6,7 36900 Leroux 2 8,5 45002 Frank 3 23,5 45002 Frank 1 4,8

    Tableau 7- 2de forme - Exemple 1

    VOIR TABLE TABLE4.DB Bien que cette table respecte la 1re forme normale, elle ne respecte par le seconde. Dans un premier temps nous devons dterminer o se trouve la cl primaire. Selon les critres mme dune cl primaire et selon le bons sens, il ne peut y avoir que quelques combinaisons permettant de reprer de faon unique chaque ligne tout en ayant une signification : Numro de salari + Numro de projet ou bien Nom + Numro de projet. Selon lutilisation qui sera faite de la table on peut renverser les cls, ce qui ne change rien leur nature. Choisissons la premire solution (nous verrons que cela ne change rien) : Numro de salari + Numro de projet. Maintenant que la cl primaire a t dfinie, regardons les champs non-cl : Nom et Heures. Les heures sont en totale dpendance fonctionnelle avec la totalit de la cl puisque cette proprit concerne la fois un individu et un projet et que seule cette combinaison permet disoler un compte dheures unique. Le nom du salari, dun autre ct, ne dpend pas de la totalit de la cl primaire. En fait il ne dpend que dun morceau de celle-ci, le numro de salari. On saperoit ici que si nous avions choisi lautre possibilit pour la cl primaire nous aurions le mme problme avec le numro de salari qui ne dpendrait que du nom et non de la totalit de cl. De fait, cette table doit tre scinde en deux autres tables qui seront :

  • Les bases de donnes relationnelles, normalisation et SQL Page 10

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    NumSalari Nom 20036 Durand 36900 Leroux 45002 Frank

    Tableau 8 - 2de forme - exemple 1 corrig 1/2

    NumSalari NumProjet Heures 20036 1 18,5 20036 2 6,7 36900 2 8,5 45002 3 23,5 45002 1 4,8

    Tableau 9 - 2de forme - exemple 2 corrig 2/2

    VOIR TABLES TABLE4C1.DB ET TABLE4C2.DB Chacune de ces tables rpond maintenant aux exigences de la premire et de la seconde forme normale. La premire ayant pour cl primaire le numro de salari, la seconde la combinaison numro de salari + numro de projet. Certains esprit chagrins feront sans doute remarquer que cette normalisation a cr la duplication de la colonne numro de salari et quil sagit dune perte de place. Nous ferons alors remarquer que sous sa forme non normalise la table obligeait la rptition du nom du salari dans chaque enregistrement ce qui, sagissant dun texte et non dun code, consomme une place trs importante. De fait, la rptition du code salari, permet au contraire de gagner beaucoup de place dans la base... Bien entendu, la normalisation que nous venons de faire subir notre table exemple na pas pour unique consquence un gain de place sur le disque dur ce qui, de nos jours, et sauf pour des bases trs grosses, na plus gure de sens (il y a peu de chances quune PME ne sature jamais un disque de 2Go - courant aujourdhui - avec sa seule activit mme en conservant lhistorique de ses ventes sur 10 ans). En fait, le rel gain a t ici dviter la rptition dune information qui peut ntre stocke quune seule fois. Eviter les rptitions homognise la base et simplifie les recherches faites sur celle-ci. De la mme faon, dans la table non normalise, si nous dtruisons le dcompte des heures du salari Durand, nous perdons aussi son nom et son numro de salari... Ce qui signifie quaprs cette purge (par exemple de fin de trimestre ou danne), ds la premire affectation de M. Durand il faudra de nouveau se renseigner pour connatre son numro de salari afin de saisir un enregistrement. Dans la version normalise on saperoit rapidement que la destruction dune enregistrement prend une signification bien prcise selon quon se trouve dans une table ou dans lautre. La suppression de tous les cumuls dheures dun salari ne dtruit pas les informations le concernant et qui nont aucun rapport avec les cumuls. Ceci est lessence mme de la normalisation. Mais ne vous laissez pas abuser par la trivialit des exemples prsents ici, dans la ralit, sur une base de plusieurs dizaines, voire centaines de tables, et dans un domaine technique que vous ne matrisez pas, la signification des champs ne vous sautera pas aux yeux, et normaliser rclamera un effort certain.

    3.3.3 Troisime forme normale (3NF)

    Voici sa dfinition : Une relation est dite dans la troisime forme normale si aucun champ non-cl nest en dpendance transitive avec la cl primaire. Ce quon peut noter aussi : soit trois colonnes (A, B, C), A tant la cl primaire, si (A B) et que (B C) on peut en dduire que (A C), dans ce cas il existe une relation transitive entre A et C et la table nest pas dans la 3NF. En fait il sagit toujours de bon sens et cette dfinition peut se comprendre facilement : si la valeur dun champ non-cl peut tre dduite de la valeur dune autre champ non-cl alors sa relation la cl primaire

  • Les bases de donnes relationnelles, normalisation et SQL Page 11

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    est, par force, transitive (puisquelle transite par un autre champ) et la table nest pas dans la troisime forme normale. Voir la 3me forme normale comme une extension de la 2de est une erreur que la trivialit des exemples proposs ici peut induire : la nature mme des exigences est totalement diffrente. Regardons la table suivante : Nom NumSalari Date Naiss. Service NomService NumChef Durand 5001 15/01/1948 5 Vente 4580 Martin 5002 12/04/1957 6 Informatique 4120

    Tableau 10 - 3me forme - exemple 1

    VOIR TABLE TABLE5.DB Cette table est dans la premire forme normale (champs atomiques, non rptitifs, ayant une signification unique constante dans le temps, prsence dune cl primaire - par exemple ici le numro de salari), elle rpond aussi aux exigences de la seconde forme normale (tous les champs non-cl sont en dpendance fonctionnelle avec la totalit de la cl primaire). Toutefois, elle nest pas dans la troisime forme normale. En effet, le nom du service ainsi que le numro de salari du chef de service sont lis la cl primaire par une relation transitive qui passe par le code du service. Il est effectivement possible de dterminer le nom du service et le code salari de son chef uniquement partir du code service. Quel problme ltat actuel va-t-il poser ? Cela se rapproche beaucoup de celui pos dans lexemple fourni pour le seconde forme normale : si nous supprimons tous les employs dune service donn, lors de la suppression du dernier enregistrement nous perdrons irrmdiablement dans le mme temps les informations concernant le service lui-mme (son nom et son chef). Cela est connu sous lappellation danomalie de suppression. De la mme faon, si on cr un nouveau service dans lentreprise nous ne pourrons pas lajouter tant quil ny aura pas un salari affect ce service. Ce problme est connu sous le nom danomalie dinsertion. Le respect de la troisime forme normale permet dviter ces anomalies. En dcoupant la table exemple en deux autres tables rpondant chacune au 3 premires formes normales tudies jusquici, nous rglerons le problmes des anomalies dinsertion et de suppression : NumSalari Nom Date naissance Service 5001 Durand 01/15/1948 5 5002 Martin 12/04/1957 6

    Tableau 11 - 3me forme - exemple 1 corrig 1/2

    Service Nom NumSalari_Chef 5 Vente 4580 6 Informatique 4120

    Tableau 12 - 3me forme - exemple 2 corrig 2/2

    VOIR TABLES TABLE5C1.DB ET TABLE5C2.DB

  • Les bases de donnes relationnelles, normalisation et SQL Page 12

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    3.3.4 Forme normale de Boyce-Codd16 (BCNF)

    Cette forme normale est une extension de la troisime forme, elle seule supprime toute dpendance transitive. Si la table possde plus dun candidat pour la cl primaire, elle doit tre examine selon le point de vue de chacune de ces cls potentielles. Si aprs un tel examen elle se trouve toujours tre dans la troisime forme normale (quel que soit la cl primaire choisie) alors elle est dans la forme normale de Boyce-Codd. Lexpression de la BCNF est dune simplicit redoutable : Une table est dans la BCNF si pour tout X Y, X est une cl. Cest tout ! Encore et toujours, il ne sagit que de bon sens... Lexemple pris pour la 2NF posait le cas de choisir la cl primaire qui pouvait tre construite soit laide du nom soit laide du code du salari. Pour que les tables (corriges) soient considres en BCNF il faut les tester jusqu' la 3NF pour chacune de ces cls possibles. Au risque dune certaine rptition, rappelons que les exemples ici fournis sont particulirement triviaux. Dans la ralit tre certain quon a bien identifi toutes les cls primaires possibles nest pas toujours vident.

    3.3.5 Quatrime forme normale (4NF)

    Elle rsout les problmes de dpendances de plusieurs valeurs, dans les tables qui en comprennent trop. Le plus simple est de prendre un exemple... Supposons une table des dpartements dune entreprise, de leurs projets (ou travaux), et des tches qui leur incombent avec les dpendances de plusieurs valeurs (DPV) suivantes : Dpartement projets Dpartement tches supposons que le dpartement D1 soccupe des projets P1 et P2 et des tches sont T1 et T2, le dpartement D2 des projets P3, P4 et P5 et des tches T2 et T4 et le dpartement D3 du projet P2 et des tches T5 et T6. La table ressemblera : Dpartement Projet Tches D1 P1 T1 D1 P1 T2 D1 P2 T1 D1 P2 T2 D2 P3 T2 D2 P3 T4 D2 P4 T2 D2 P4 T4 D2 P5 T2 D2 P5 T4 D3 P2 T5 D3 P2 T6

    Tableau 13 - 4me forme - exemple 1

    Si on veut ajouter une tche un dpartement, il faut crer plusieurs lignes nouvelles (puisquil faudra gnrer et maintenir toutes les combinaisons possibles avec les projets). On risque ainsi, en supprimant une tche ou un projet dune ligne de perdre des informations. Pour mettre jour le nom dune tche ou dun projet il faudra aussi rpter lopration sur plusieurs lignes.

    16 Le Dr E.F. Codd a t le premier a dfinir le modle relationnel et les formes normales de celui-ci (Codd 1970). Cest lui qui inventa le terme de relation normalise calqu sur le jargon politique de lpoque.

  • Les bases de donnes relationnelles, normalisation et SQL Page 13

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    La solution consiste rpartir les donnes en deux tables lune tablie daprs (Dpartement, Projets) et lautre daprs (Dpartements, Tches). On peut en fait simplifier lexpression de la 4NF en disant quil ne faut conserver quune seule DPV par table. La table exemple ci-dessus se transforme alors en : Dpartement Projet D1 P1 D1 P2 D2 P3 D2 P4 D2 P5 D3 P2

    Tableau 14 - 4me forme - exemple 1 corrig 1/2

    Dpartement Tche D1 T1 D1 T2 D2 T2 D2 T4 D3 T5 D3 T6

    Tableau 15 - 4me forme - exemple 1 corrig 2/2

    En fait, partir de laspect physique des tables pour effectuer la normalisation nest pas forcment une dmarche trs acadmique . Lexemple que nous avons pris simplifie certes la comprhension de la 4NF mais dans la ralit, et si nous tions parti du modle conceptuel propre nous naurions obtenu ni la table de lexemple ni mme les deux tables du corrig. Cela est important car il faut comprendre que si on choisit de travailler proprement ds le dpart, notamment en utilisant des outils CASE comme AMC Designor ou Win-Design, on limine beaucoup de problmes de dnormalisation car la notation Entit-Relation finit par imposer sa propre logique. Dans notre exemple il faudra soccuper ds le dpart des cardinalits, notamment savoir si un projet ou une tche peuvent tre partags par plusieurs dpartement ou bien si une tche ou un projet sont toujours affects un seul et unique dpartement (on peut aussi envisager les combinaisons mixtes). Nous allons tudier rapidement les deux versions avec leur MCD et leur MPD respectif : 1er cas : les projets et les tches peuvent tre partags par plusieurs dpartements :

    0,n

    0,n

    0,n

    0,nDpartementNom A60

    ProjetNom A60

    TcheNom A60

    travaille sur

    doit raliser

    Figure 3 - 4NF - MCD 1

    On notera les cardinalits 0,N sur lensemble des branches. Le MPD de cette reprsentation donnera :

  • Les bases de donnes relationnelles, normalisation et SQL Page 14

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    DEPARTEMENTS

    NOMDEPARTEMENT CHAR(60) not null

    DEPARTEMENTS_PK

    PROJETS

    NOMPROJET CHAR(60) not null

    PROJETS_PK

    TACHES

    NOMTACHE CHAR(60) not null

    TACHES_PK

    TRAVAILLESUR

    NOMDEPARTEMENT CHAR(60) not nullNOMPROJET CHAR(60) not null

    TRAVAILLESUR_PK

    DOITREALISER

    NOMDEPARTEMENT CHAR(60) not nullNOMTACHE CHAR(60) not null

    DOITREALISER_PK

    Figure 4 - 4NF - MPD 1

    On note ici lapparition de deux tables supplmentaires charges de maintenir les relations 0,N. 2me cas : Les projets et les tches ne peuvent tre affects qu un seul dpartement la fois

    0,1

    0,n

    0,1

    0,nDpartementNom A60

    ProjetNom A60

    TcheNom A60

    travaille sur

    doit raliser

    Figure 5 - 4NF - MCD 2

    On note ici les cardinalits 0,1 du ct des projets et des tches. Le MPD deviendra alors :

    DEPARTEMENTSNOMDEPARTEMENT CHAR(60) not null

    DEPARTEMENTS_PK

    PROJETSNOMPROJET CHAR(60) not nullNOMDEPARTEMENT CHAR(60) null

    PROJETS_PKTRAVAILLESUR_FK

    TACHESNOMTACHE CHAR(60) not nullNOMDEPARTEMENT CHAR(60) null

    TACHES_PKDOITREALISER_FK

    Figure 6 - 4NF - MPD 2

    Il est clair que partant dun MCD prcisant ds le dpart les cardinalits (que seule lanalyse fonctionnelle peut permettre de dterminer) on aboutit des reprsentations physiques qui ne ressemblent en rien aux tables de lexemple. Ce petit exercice sur un outil CASE nous permet ainsi de mettre en vidence lutilit dun formalisme respect ds le dbut de la conception dune base de donnes.

    3.3.6 Cinquime forme normale (5NF)

    La 5me forme normale est aussi appele join-Protection ou JPNF ou forme normale Protection-Join. Elle repose sur la ncessit de se prmunir contre la perte dune jointure ou de pallier une anomalie due labsence de join-protection.

  • Les bases de donnes relationnelles, normalisation et SQL Page 15

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Ce problme se rencontre lorsquon a une relation N-vers-N o N > 2. Il existe une mthode de vrification rapide de la 5NF : regarder si la table est en 3NF et si toutes les cls candidates sont des colonnes uniques. Voici un exemple de problme rsolu par 5NF : Soit une table enregistrant lacheteur, le vendeur et la banque suivante : Acheteur Vendeur Banque Durand Frank BNP Durand Leroux SBC Martin Frank SBC

    Tableau 16 - 5me forme - exemple 1

    VOIR TABLE TABLE6.DB Cette table est une relation triple, mais la majorit des outils CASE nautorise que des relations binaires. De fait, on pourrait tre tent de reformuler cette table dans un schma E-R17 sous la forme de trois relations binaires qui donneront naissance trois tables : Table AcheteurBanque Acheteur Banque Durand BNP Durand SBC Martin SBC

    Tableau 17 - 5me forme - Exemple 2 1/3

    Table VendeurBanque Vendeur Banque Frank BNP Leroux SBC Frank SBC

    Tableau 18 - 5me forme - Exemple 2 2/3

    Table AcheteurVendeur Acheteur Vendeur Durand Frank Durand Leroux Martin Frank

    Tableau 19 - 5me forme - exemple 2 3/3

    VOIR TABLES TABLE6C1.DB TABLE6C2.DB ET TABLE6C3.DB Il y a un problme quand on essaie dassembler linformation originelle en joignant ces trois tables par paires ce qui sera rgl par lordre SQL suivant : SELECT AV.Acheteur, VB.Vendeur, AB.Banque FROM table6c1 as AB, table6c2 as VB, table6c3 as AV WHERE AB.acheteur = AV.Acheteur AND AB.banque = VB.Banque AND VB.vendeur = AV.vendeur VOIR REQUTE QUERY1.SQL 17 E-R : Entit-Relation

  • Les bases de donnes relationnelles, normalisation et SQL Page 16

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Toutefois le rsultat de cette requte comptera des lignes comme (Durand, Frank, SBC) qui nexistent absolument pas dans la table dorigine ! Cest ce quon appelle une anomalie de join-protection18. Rsultat de la requte ci-dessus : Acheteur vendeur Banque Durand Frank BNP Durand Frank SBC Durand Leroux SBC Martin Frank SBC Copie de la table originale pour comparaison : Acheteur Vendeur Banque Durand Frank BNP Durand Leroux SBC Martin Frank SBC En fait il est possible dviter (ou tout cas de minimiser largement) les anomalies de join-protection en concevant de bons modles conceptuels. Si nous reprenons le mme exemple et que nous tablissons un MCD correct, nous obtiendrons quelque chose comme :

    1,1

    0,n

    1,1

    0,n

    1,1

    0,n

    BanqueNom A30

    AcheteurNom A30

    VendeurNom A30

    TransactionCode NO

    est impliqu dans

    est impliqu dans

    est impliqu dans

    Figure 7- 5NF - MCD 1

    On voit quici nous avons isols trois entits bien diffrentes lacheteur, le vendeur et la banque et que lanalyse du problme nous force crer une quatrime entit qui est la transaction. Une transaction possde un code (ici squentiel) qui est sa cl primaire, elle entre en relation avec les trois autres entits. Vous noterez les cardinalits, 0,N du ct des entits de base de notre exemple et 1,1 du ct de la transaction. Si nous navions pas ajout une cl primaire la transaction ( code ), nous aurons utilis des liens identifiants la place de simple liens 1,1. De fait, la transformation automatique en MPD par un outil CASE de ce MCD donnera :

    18 Il faut dailleurs diffrencier les JPNF puissantes et les JPNF surpuissantes qui font usage de dpendances de jointures (JD). Malheureusement il nexiste aucune manire systmatique de trouver un schma en JPNF ou 4NF parce que le problme est connu pour tre NP-complet.

    Anomalie !

  • Les bases de donnes relationnelles, normalisation et SQL Page 17

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    BANQUESNOMBANQUE CHAR(30) not null

    BANQUES_PK

    ACHETEURSNOMACHETEUR CHAR(30) not null

    ACHETEURS_PK

    VENDEURSNOMVENDEUR CHAR(30) not null

    VENDEURS_PK

    TRANSACTIONSCODE SMALLINT not nullNOMBANQUE CHAR(30) not nullNOMVENDEUR CHAR(30) not nullNOMACHETEUR CHAR(30) not null

    TRANSACTIONS_PK

    Figure 8 - 5NF - MPD 1

    Sous cette forme lensemble de tables est en 5NF car nous avons cr une table qui symbolise conceptuellement et physiquement la relation sous-jacente de lexemple qui ne lexprimait que de faon virtuelle. Souvent rpondre la 5NF nest quun problme danalyse. Lexemple original masquait lexistence dune entit particulire qui tait la transaction en tant lui-mme la table des transactions... Il faut, par contre, toujours gard prsent lesprit que la normalisation est un travail qui peut tre entrepris deux instants diffrents : la conception de la base de donnes, ce qui est prfrable (nos exemples laide doutils CASE le montrent assez bien), ou sur une base de donnes existante. Le plus difficile tant bien entendu de vrifier, voire de corriger, une base de donnes existante non normalise.

    3.3.7 Forme normale Domain-Key (DKNF)

    Nous ne citerons cette forme que pour tre complet car sa dfinition et les mthodes de normalisation affrentes deviennent fort complexes. Cette forme a t dcrite et nomme par R.Fagin en 1981 Une dpendance fonctionnelle (DF) a un systme dfini daxiomes qui peuvent tre utiliss pour la normalisation. Il existe six axiomes connus sous le nom daxiomes dAmstrong qui peuvent tre appliqus la rsolution de la DKNF. Certains algorithmes comme ceux dvelopps par P.A. Bernstein (1976) permettent de se librer des problmes des redondance des DF. Nous nentrerons pas dans les dtails de cette forme normale et nous renverrons le lecteur la littrature spcialise.

    3.3.8 Conclusion

    Il y a dun ct les puristes qui considrent que ne pas amener un schma au niveau minimum de la 3NF est un crime, de lautre ceux qui par des ALTER TABLE ajoute et supprime des colonnes dans leurs bases de donnes sans trop se soucier de lintgrit de lensemble. Comme souvent la solution se trouve quelque part entre les extrmes... Le bon conseil est certainement celui dutiliser un outil CASE pour concevoir de bons modles conceptuels puis de gnrer les MPD et, ponctuellement, dappliquer des dnormalisations justifies dont on assumera, ds le dpart, la totalit des consquences. Les gens qui sont issus de linformatique lourde ou qui nutilisaient pas de SGBD-R ont tous lhabitude de concevoir des tables de grande taille qui contiennent de nombreuses colonnes. Cela tait justifi lorsquil fallait monter et dmonter des bandes magntiques, cela ltait dj moins avec lapparition des disques durs, cela nest plus raisonnable du tout ds quon adopte un SGBD-R. Toutefois la normalisation entrane la multiplication des tables ne contenant que peu de colonnes. Accder aux donnes utilisera de nombreuses jointures ce qui peut ralentir les applications. De mme, la saisie peut savrer plus complexe mettre en uvre avec un schma normalis. A chacun de savoir o sarrter dans la normalisation dune base, la seule chose qui compte rellement est peut-tre, simplement, de savoir ce que veut dire normalisation et de ne dnormaliser quen parfaite connaissance des causes et effets. Le savoir est toujours prfrable lignorance...

  • Les bases de donnes relationnelles, normalisation et SQL Page 18

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    4. SQL et Delphi Dans cette section nous aborderons des applications pratiques du SQL au travers dappels directs tels quils peuvent tre fait dans le module de base de donnes de DELPHI 3 ou dans le WISQL dInterbase ou par le biais dun TQUERY en programmation sous DELPHI. De fait, nous illustrerons parfaitement la parfaite indpendance entre applicatif et gestion des donnes (Cf. : Rgles 8, 5 et 10 de Codd). Nous naborderons pas directement la programmation des bases de donnes avec DELPHI, thme qui mrite plus quun simple expos. Rappelons que la VCL est dote de deux palettes de composants entirement ddis la gestion des donnes et que la nouvelle architecture multi-tiers de DELPHI 3 ouvre de nouveaux horizons (sources de donnes non BDE) tout en bnficiant dune mme interface de dveloppement. Ct SQL, les outils principaux mis disposition par DELPHI sont le TQUERY, qui permet lexcution de requtes, et le TStoredProc qui donne accs aux procdures stockes dans le serveur. Dautres composants jouent un rle essentiel, comme le TDataBase (assurant la liaison avec une base ou permettant de grer les transactions) ou le Tsession (contrlant les sessions ouvertes). Afin de rendre plus visuelles nos dmonstrations (et de prouver, tout en ne labordant pas, lextraordinaire puissance de DELPHI puisque loutil est crit avec D3) nous avons choisi dutiliser le MKQB (Visual Query Builder de la socit MKO) dans sa version 2 entirement reprogramme sous DELPHI 3, version qui est mise sur le march en ce moment19 (octobre / novembre 1997). En quelques mots, cet outil est un composant natif VCL qui permet au dveloppeur de proposer un systme de requettage libre, mais contrl, aux utilisateurs de ses logiciels. Loutil gnre automatiquement le code SQL partir des reprsentations graphiques des tables et des jointures et des champs et conditions choisis. Il permet dexploiter les donnes de nombreuses faons (dont un expert dimpression et un autre dexportation de donnes). Nous lutiliserons ici sous la forme dun module stand-alone pour reprsenter les tables et les jointures (accessoirement le code SQL prsent est celui gnr par loutil), la reprsentation tant plus proche de notre besoin quun MCD ou un MPD.

    4.1 Le langage SQL Prsentation Il existe actuellement plusieurs normes SQL ANSI / ISO. Le standard SQL-89 est celui qui est le mieux support aujourdhui par lensemble des serveurs du march. SQL-92, qui est compatible avec SQL-89, ajoute de nombreuses possibilits mais son support est loin dtre gal. Il existe des normes encore plus rcentes mais pour lesquelles personne ne sattend voir de rel support avant longtemps (mme si, ponctuellement, les versions rcentes de certains serveurs comme Interbase proposent dj des implmentations de certaines fonctionnalits). Il est ainsi trs difficile de parler du SQL de faon gnrique puisquil existe autant de version de ce langage quil y a de SGBD-R sur le march. Nous utiliserons ici le SQL local du BDE 4 ou celui dInterbase. Il est intressant de noter que Interbase de Borland offre un support de bonne qualit du SQL-92 notamment syntaxique l o dautres serveurs pourtant de rputations mondiales comme Oracle ou Sybase noffre parfois que des syntaxes exotiques non conforment aux normes. La norme SQL-92 se prsente sur trois niveaux : restreint, intermdiaire et complet. Mme si la tendance va vers un support complet, on aura compris quaucun produit du march noffre pour linstant ce niveau. Pour terminer avec les gnralits, ajoutons que le NIST (National Institute for Standards and Technology) aux USA propose un ensemble de FIPS (Federal Information Processing Standards) qui comprennent des squences de test pour diffrents langages de programmation, dont SQL (sries FIPS-127). Dailleurs, pour faire une offre de contrat au gouvernement amricain, il faut avoir pass avec succs les tests des FIPS. Les FIPS concernant SQL sont segments en plusieurs couches rpondant des fonctionnalits prcises de telle sorte que les diteurs puissent se faire certifier pour un niveau donn sans tre obligs de supporter tout SQL-92 ou tre rejet dfinitivement.

    19 Les personnes intresses par ce produit trouveront toutes les informations auprs de la socit MKO, 13 rue Fernand Lger, 75020 Paris, tlphone : 01-4358-6161, site Web : http ://www.mko.fr

  • Les bases de donnes relationnelles, normalisation et SQL Page 19

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Enfin, on pourra sintresser aux travaux du SQL / Access Group qui est un consortium dditeurs traitant de linteractivit entre bases de donnes ou ceux de X / Open, autre consortium dditeurs traitant de la portabilit du langage SQL. La plupart de diteurs appartenant ces groupes sont membres du comit de standardisation X3H2 ANSI sintressant au SQL.

    4.2 Les grandes fonctions de SQL SQL se prsente comme un langage deux couches : le DDL et le DML. Le DDL (Data Definition Language) permet de crer des bases de donnes, les tables qui en font partie, les champs, les index, etc. Le DML (Data Manipulation Language) permet dexploiter les donnes : ajouter, supprimer des enregistrements, interroger les donnes. A ct de ces couches ddies on trouvent le plus souvent un langage procdural driv de SQL qui permet de crer des procdures stockes ou des triggers.

    4.2.1 Les fonctions du DDL

    Les trois fonctions principales du DDL sont : CREATE TABLE, DROP TABLE et ALTER TABLE. Des fonctions annexes sont aussi proposes pour manipuler de faon isole les contraintes et les index. On trouve aussi des fonctions ddies la manipulations des mta-donnes comme les domaines. Certains serveurs (comme Interbase) proposent aussi la cration de bases de donnes directement en SQL.

    4.2.1.1 CREATE TABLE Cette instruction permet de crer de nouvelles tables. Elle soccupe de renseigner automatiquement les tables systme (sauf en SQL local dBase ou Paradox puisquil ny a pas de telles tables). La syntaxe dans Interbase est : CREATE TABLE table [EXTERNAL [FILE] ""] ( [, | ...]); o table est le nom de la table crer

    External permet dutiliser des donnes stockes en dehors de la base. il sagit dune spcificit Interbase.

    Col_def est la dfinition dune colonne. Interbase supporte une syntaxe assez large : = col {datatype | COMPUTED [BY] () |

    domain} [DEFAULT {literal | NULL | USER}]

    [NOT NULL] [] [COLLATE collation]

    constraint Contraintes. On verra ci-dessous la richesse (et la complexit)

    des contraintes :

    = {UNIQUE | PRIMARY KEY | CHECK () | REFERENCES other_table [(other_col [, other_col ...])]} = CONSTRAINT constraint [] = {{PRIMARY KEY | UNIQUE} (col [, col ...])

  • Les bases de donnes relationnelles, normalisation et SQL Page 20

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    | FOREIGN KEY (col [, col ...]) REFERENCES other_table | CHECK ()} = { { | ()} | [NOT] BETWEEN AND | [NOT] LIKE [ESCAPE ] | [NOT] IN ( [, ...] | ) | IS [NOT] NULL | {[NOT] {= | < | >} | >= | | = | !< | !> | | !=} = SELECT on a single column that returns exactly one value. = SELECT on a single column that returns zero or more values. = SELECT on a list of values that returns zero or more valu

    Le but du prsent article ntant pas de dissquer en profondeur le SQL, nous nirons pas plus loin dans ltude du CREATE TABLE.

    4.2.1.2 ALTER TABLE SQL permet de modifier les caractristiques dune table existante, ce qui savre trs pratique.

  • Les bases de donnes relationnelles, normalisation et SQL Page 21

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Interbase offre la syntaxe suivante : ALTER TABLE table [, ...]; = {ADD | ADD | DROP col | DROP CONSTRAINT constraint} = col { | [COMPUTED [BY] () | domain} [DEFAULT {literal | NULL | USER}] [NOT NULL] [] [COLLATE collation]

    4.2.1.3 DROP TABLE Cette instruction a un effet ... radical... puisquelle supprime dfinitivement une table. La syntaxe est rudimentaire : DROP TABLE name;

    4.2.1.4 Les autres ordres du DDL Suivant les serveurs ces ordres peuvent diffrer ou tre totalement absents. Interbase offre ici : CREATE DATABASE pour crer une base CREATE DOMAIN pour crer des domaines CREATE EXCEPTION pour crer des erreurs personnalises CREATE GENERATOR pour crer des nombres squentiels uniques CREATE INDEX pour ajouter des index CREATE PROCEDURE pour crer des procdures stockes CREATE TRIGGER pour crer des triggers CREATE VIEW pour crer des vues CREATE SHADOW pour crer une base miroir On trouve aussi des ordres ALTER correspondants chaque CREATE, ainsi que dautres fonctions propres Interbase comme la dfinition de procdures externes en DLL pour tendre le langage de base.

    4.2.2 Les fonctions du DML

    Les principales fonctions sont ici : INSERT INTO, DELETE FROM, UPDATE et SELECT Ces ordres permettent, respectivement, dinsrer de nouveaux enregistrements, de supprimer, ou de modifier des enregistrements existants et enfin dinterroger la base de donnes. Voici la syntaxe Interbase des trois premiers, lordre SELECT tant prsent plus dtail la section suivante :

    INSERT INTO [(col [, col ...])] {VALUES ( [, ...]) | }; DELETE FROM TABLE [WHERE ]; UPDATE {table | view} SET col = [, col = ...] [WHERE ;

  • Les bases de donnes relationnelles, normalisation et SQL Page 22

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    4.2.3 Lordre SELECT

    Il permet de ... slectionner des donnes dans une base de donnes relationnelle. Il est capable de comprendre les jointures et de croiser les diffrentes donnes pour fournir le rsultat. Limportance de cette instruction qui illustre parfaitement laspect relationnel fait quil bnficie de sa propre section que voici. La syntaxe de lordre SELECT pour le SQL local du BDE est :

    SELECT [DISTINCT] liste_colonnes FROM rfrence_table [WHERE condition_recherche] [ORDER BY liste_tri] [GROUP BY liste_groupe] [HAVING condition_having] [UNION expr_select]

    Loprateur DISTINCT permet de limiter les lignes retournes en supprimant les doublons. La liste des colonnes est la liste des noms des champs quon dsire afficher dans la table rsultat. On peut bien entendu afficher certains champs et faire des tests ou exprimer des jointures sur dautres, il ny a pas de jonction entre ces deux oprations (afficher lge et le nom des lves dune classe ayant obtenu une note gnrale suprieure 10 par exemple).

    La clause FROM permet de prciser la provenance des donnes (tables ou sous requte ). Selon les serveurs cette clause permet aussi dexprimer les jointures internes et externes.

    La clause WHERE permet de filtrer les donnes en imposant des conditions tout autant que dexprimer des jointures (quivalences entre des champs de tables diffrentes).

    La clause ORDER BY permet de trier le rsultat. La clause GROUP BY est utilise pour grouper les donnes afin dobtenir des rsultats

    synthtiques (en conjonction avec des fonctions dagrgat de donnes comme SUM, AVG...).

    la clause HAVING est une option au sein de la prcdente en imposant certaines conditions aux donnes groupes (un peu comme un WHERE).

    La clause UNION permet de combiner le rsultat de plusieurs ordres SELECT afin dobtenir une seule table rsultat.

    4.2.3.1 Exemple 1 : Slection et Tri Ce premier exemple nutilise quune seule table et dmontre les capacits de slection et de tri de SQL.

  • Les bases de donnes relationnelles, normalisation et SQL Page 23

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    VOIR MODLE SAMPLE1.DML ET QUERY1.QRY Nous utilisons ici la table exemple 1 corrige (voir Tableau 2 - Atomicit des champs, 1re forme, exemple 1 corrig, p 6) Le but est dextraire toutes les personnes habitant dans les dpartement 75 80 et de trier le rsultat par Nom et Prnom. Le texte SQL de cet exemple est :

    SELECT T1."Nom", T1."Prnom", T1."Dpartement" FROM "Table1 corrige.db" T1 WHERE (T1."Dpartement" BETWEEN 75 AND 80) ORDER BY T1."Nom" ASC, T1."Prnom" ASC

    Le rsultat est :

    Commentaires : Lordre SELECT est suivi du nom des champs inclure dans la table rponse. Les champs Paradox comportant des accentues nous sommes obligs de les placer entre guillemets. De fait, un texte ainsi dlimit est normalement une constante en SQL, nous sommes donc ici oblig de prfixer chaque champs par le nom de table afin de lever lambigut syntaxique. Le prfixage est aussi ncessaire lorsque le mme nom de champ apparat dans plusieurs tables faisant partie de la slection. Le prfixe de table est un alias (au sens propre, rien voir avec les alias du BDE). Les alias de table sont dfinis dans la clause FROM, juste aprs le nom physique de chaque table.

  • Les bases de donnes relationnelles, normalisation et SQL Page 24

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    La clause WHERE permet de filtrer les donnes, ici on utilise loprateur BETWEEN (entre) pour limiter les valeurs celles comprises entre 75 et 78. Les bones sont inclusives. Enfin, la clause ORDER BY permet de fixer un ordre de tri pour les donnes de la table rsultat. Rappelons quune requte na pas dindex et lordre des enregistrements est celui dict par lordre dans lequel, en interne, le moteur de base de donnes traitent les instructions. Chaque champs de la clause ORDER BY peut tre suivi dun indicateur du sens du tri (ASC ou ASCENDING, DESC ou DESCENING).

    4.2.3.2 Exemple 2 : Jointure interne standard Dans cet exemple nous mettrons en uvre une jointure simple. Nous utiliserons les tables corriges des tableaux : Tableau 4 - 1re forme - Exemple 2 corrig - 1/2, et Tableau 5 - 1re forme - Exemple 2 corrig - 2/2, page 7.

    VOIR MODELE2.DML ET QUERY2.QRY Le but est ici dobtenir la liste de tous les livres emprunts classs dans lordre alphabtique du nom de lemprunteur. La requte SQL est :

    SELECT T1."Nom_emprunteur", T2."Livre" FROM "TABLE2C1.db" T1 , "TABLE2C2.db" T2 WHERE (T1."Numro_emprunteur" = T2."Emprunt_par") ORDER BY T1."Nom_emprunteur" ASC

    Le rsultat est :

  • Les bases de donnes relationnelles, normalisation et SQL Page 25

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Commentaires : La jointure entre les table est effectue dans la clause WHERE en filtrant les donnes rsultante sur lgalit des deux champs reprsentant lemprunteur. Nous verrons dans lexemple suivant comment crire autrement une jointure interne.

    4.2.3.3 Exemple 3 : Jointure Interne et Statistiques Dans lexemple qui suit nous allons dmontrer les possibilits statistiques de lordre SELECT. Nous utiliserons nouveau les tables des Tableau 4 - 1re forme - Exemple 2 corrig - 1/2, et Tableau 5 - 1re forme - Exemple 2 corrig - 2/2, page 7.

    VOIR MODELE3.DML ET QUERY3.QRY Le but ici est de savoir combien chaque personne a emprunt de livres. La requte SQL est :

    SELECT T1."Nom_emprunteur", COUNT(DISTINCT T2."Livre") FROM "TABLE2C1.db" T1 INNER JOIN "TABLE2C2.db" T2 ON (T1."Numro_emprunteur" = T2."Emprunt_par") GROUP BY T1."Nom_emprunteur"

  • Les bases de donnes relationnelles, normalisation et SQL Page 26

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    Le rsultat est :

    Commentaires : Nous avons utilis ici une notation plus acadmique pour la jointure interne en exploitant la syntaxe du INNER JOIN. Dans un tel cas, la jointure est exprime dans la clause FROM sous la forme Table1 INNER JOIN Table2 ON (liste dgalits) Sil ny a pas de filtrage supplmentaire, ce qui est le cas de notre exemple, la clause WHERE disparat. Il est vident quil est plus prcis dexprimer les jointures dans le FROM et de laisser le WHERE soccuper du filtrage. Toutefois tous les serveurs ne supportent pas cette syntaxe. La clause GROUP BY permet de grouper les rsultats selon un ou plusieurs champs nomms dans le SELECT. Tous les autres champs de lordre SELECT napparaissant pas dans le GROUP BY sont, par force, traits par des ordres dagrgat. Ici nous utilisons un COUNT DISTINCT sur le nom du livre emprunt.

    4.2.3.4 Exemple 4 : Statistiques Voici un autre exemple de statistiques en utilisant les tables des Tableau 8 - 2de forme - exemple 1 corrig 1/2 et Tableau 9 - 2de forme - exemple 2 corrig 2/2 page 10.

    VOIR MODELE4.DML ET QUERY4.QRY Le but est ici de connatre les temps total et moyen passs par chaque salari sur lensemble des projets qui lui sont confis. La requte SQL est :

  • Les bases de donnes relationnelles, normalisation et SQL Page 27

    Confrence Borland 4/5 nov 97 - Confrence DL210 + Sept 98 Version 20/07/2000 02:51 O.Dahan

    SELECT T1."Nom", SUM( T2."Heures" ) Cumul_Total, AVG( T2."Heures" ) Temps_moyen FROM "TABLE4C1.db" T1 INNER JOIN "TABLE4C2.db" T2 ON (T1."NumSalari" = T2."NumSalari") GROUP BY T1."Nom"

    Le rsultat est :

    Commentaires : La requte utilise la possibilit de nommer les champs calculs. Dailleurs tous les champs dun ordre SELECT peuvent tre ainsi renomms. La syntaxe varie dune serveur lautre. En local le BDE accepte que lalias de champs soit plac juste derrire le champ.

    5. Conclusion Aprs avoir abord les fondements conceptuels des SGBD-R (rgles de Codd), la normalisation des bases de donnes ainsi que les grandes lignes du SQL lauteur espre non pas vous avoir converti au relationnel ni mme vous avoir enseign lart de la normalisation, mais vous avoir simplement donn lenvie la fois de lire la littrature spcialise et celle de mettre en uvre des applications bien conues laide de DELPHI qui est, aujourdhui, le seul vrai outil RAD compil orient objet avec C++ Builder (moins pratique toutefois en raison de la structure mme du langage et des restrictions imposes par la norme ANSI). Au-del de cet aspect technique (toutefois essentiel) DELPHI est un environnement qui donne un grand plaisir toujours renouvel, et prendre du plaisir dvelopper sous Windows dont lopacit des API est plus que lgendaire, si ce nest pas un miracle, cela y ressemble beaucoup... Et Lavenir ? Une fois que vous serez parfaitement laise avec la programmation oriente objet et avec les SGBD-R, vous vous rendrez vite compte que la premire cre de nouveaux besoins auxquels les secondes ne peuvent pas totalement rpondre. Le Relationnel a ses limites. Demain, les bases de donnes objet seront une ralit en micro-informatique. On trouve dors et dj certaines bases de ce type des prix attractifs, toutefois elles restent assez lentes et peu ou pas intgres dans les grands EDI du march. Mais cela viendra bientt... D'ailleurs, lorsque je concluais ainsi l'anne dernire je ne savais pas encore que les mois qui suivraient me donneraient tant raison En effet, les extensions Objet de Oracle 8, mme si elles ne sont qu'un dbut partiel et timide, dmontrent que l'avenir est bien l'objet, mme pour les bases de donnes Raison de plus pour vous intresser ds maintenant la programmation oriente objet ainsi quaux concepts des SGBD-R... Il est toujours plus difficile de prendre un train en route que dtre dj install quand il dmarre... Olivier Dahan.