Changeset 786

Show
Ignore:
Timestamp:
11/07/07 18:53:29 (1 year ago)
Author:
sas
Message:

Toute petite modif

Files:

Legend:

Unmodified
Added
Removed
Modified
Copied
Moved
  • traduc/branches/bv82x/manuel/arch-dev.xml

    r590 r786  
    2020   Ce chapitre présente la structure interne du serveur 
    2121   <productname>PostgreSQL</productname>.  
    22    La lecture des sections qui suivent permet de se faire une idée sur la 
     22   La lecture des sections qui suivent permet de se faire une idée de la 
    2323   façon dont une requête est exécutée&nbsp;; les opérations 
    2424   internes ne sont pas décrites dans le détail. 
     
    127127    processus serveur. Les tâches du serveur communiquent entre elles en 
    128128    utilisant des <firstterm>sémaphores</firstterm> et de la <firstterm>mémoire 
    129     partagée</firstterm> pour s'assurer de l'intégrité des données lors d'un 
    130     accès simultané aux données. 
    131    </para> 
    132  
    133    <para> 
    134     Le processus client peut consister en tout programme comprenant le protocole 
     129    partagée</firstterm> pour s'assurer de l'intégrité des données lors d'accès 
     130    simultanés aux données. 
     131   </para> 
     132 
     133   <para> 
     134    Le processus client est constitué de tout programme comprenant le protocole 
    135135    <productname>PostgreSQL</productname> décrit dans le 
    136136    <xref linkend="protocol"/>. De nombreux clients s'appuient sur la 
    137     bibliothèque C <application>libpq</application> mais il existe 
     137    bibliothèque C <application>libpq</application>, mais il existe 
    138138    différentes implantations indépendantes du protocole, tel que le pilote Java 
    139139    <application>JDBC</application>. 
     
    159159     <listitem> 
    160160      <para> 
    161        L'<firstterm>analyseur</firstterm> défini dans 
    162        <filename>gram.y</filename> et <filename>scan.l</filename> est construit 
     161       l'<firstterm>analyseur</firstterm>, défini dans 
     162       <filename>gram.y</filename> et <filename>scan.l</filename>, est construit 
    163163       en utilisant les outils Unix <application>yacc</application> et 
    164        <application>lex</application>. 
     164       <application>lex</application>&nbsp;; 
    165165      </para> 
    166166     </listitem> 
    167167     <listitem> 
    168168      <para> 
    169        Le <firstterm>processus de transformation</firstterm> fait des 
     169       le <firstterm>processus de transformation</firstterm> fait des 
    170170       modifications et des ajouts aux structures de données renvoyées par 
    171171       l'analyseur. 
     
    210210     <application>yacc</application>. Après avoir réalisé ces transformations, 
    211211     un compilateur C normal peut être utilisé pour créer l'analyseur. Il 
    212      est inutile de modifier les fichiers C engendrés car ils seront écrasés 
    213      au prochaine appel de <application>lex</application> ou 
     212     est inutile de modifier les fichiers C engendrés car ils sont écrasés 
     213     à l'appel suivant de <application>lex</application> ou 
    214214     <application>yacc</application>. 
    215215 
     
    244244     fixes de la structure syntaxique de SQL. Il ne fait aucune recherche dans 
    245245     les catalogues système. Il n'y a donc aucune possibilité de comprendre 
    246      la sémantique détaillée des opérations demandées. Après que l'analyseur 
    247      ait fini, le <firstterm>processus de transformation</firstterm> prend 
     246     la sémantique détaillée des opérations demandées. Lorsque l'analyseur 
     247     a fini, le <firstterm>processus de transformation</firstterm> prend 
    248248     en entrée l'arbre résultant de l'analyseur et réalise l'interprétation 
    249249     sémantique nécessaire pour connaître les tables, fonctions et opérateurs 
     
    298298     <listitem> 
    299299      <para> 
    300        La première, qui fonctionnait au <firstterm>niveau des 
     300       la première, qui fonctionnait au <firstterm>niveau des 
    301301       lignes</firstterm>, était implantée profondément dans 
    302302       l'<firstterm>exécuteur</firstterm>. Le système de règles était appelé 
     
    304304       implantation a été supprimée en 1995 quand la dernière version 
    305305       officielle du projet <productname>Berkeley Postgres</productname> a été 
    306        transformée en <productname>Postgres95</productname>.  
     306       transformée en <productname>Postgres95</productname>&nbsp;; 
    307307      </para> 
    308308     </listitem> 
     
    310310     <listitem> 
    311311      <para> 
    312        La deuxième implantation du système de règles est une technique appelée 
    313        la <firstterm>réécriture de requêtes</firstterm>. Le <firstterm>système 
     312       la deuxième implantation du système de règles est une technique appelée 
     313       <firstterm>réécriture de requêtes</firstterm>. Le <firstterm>système 
    314314       de réécriture</firstterm> est un module qui existe entre 
    315315       l'<firstterm>étape d'analyse</firstterm> et le 
     
    356356 
    357357   <para> 
    358     La procédure de recherche du planificateur fonctionne en fait avec des 
     358    La procédure de recherche du planificateur fonctionne avec des 
    359359    structures de données appelés <firstterm>chemins</firstterm>, simples 
    360360    représentations minimales de plans ne contenant que l'information 
    361361    nécessaire au planificateur pour prendre ses décisions. Une fois 
    362362    le chemin le moins coûteux déterminé, un <firstterm>arbre plan</firstterm> est 
    363     construit pour être passé à l'exécuteur. Ceci représente le plan d'exécution 
     363    construit pour être passé à l'exécuteur. Celui-ci représente le plan d'exécution 
    364364    désiré avec suffisamment de détails pour que l'exécuteur puisse le lancer. 
    365365    Dans le reste de cette section, la distinction entre chemins et plans 
     
    411411        (Toutefois, si la relation de droite peut être parcourue à l'aide d'un 
    412412        index, ceci peut être une bonne stratégie. Il est possible d'utiliser 
    413         les valeurs issues de la ligne actuelle de la relation de gauche comme 
     413        les valeurs issues de la ligne courante de la relation de gauche comme 
    414414        clés du parcours d'index à droite.) 
    415415       </para> 
     
    427427        Le tri requis peut être réalisé soit par une étape explicite de tri 
    428428        soit en parcourant la relation dans le bon ordre en utilisant un index 
    429         sur la clé de la jointure. 
     429        sur la clé de la jointure&nbsp;; 
    430430       </para> 
    431431      </listitem> 
     
    460460     La plupart des types de n&oelig;ud de plan ont la capacité supplémentaire de faire une 
    461461     <firstterm>sélection</firstterm> (rejet des lignes qui ne correspondent pas à une 
    462      condition booléenne spécifiée) et une <firstterm>projection</firstterm> (calcul d'un 
     462     condition booléenne indiquée) et une <firstterm>projection</firstterm> (calcul d'un 
    463463     ensemble dérivé de colonnes fondé sur des valeurs de colonnes données, 
    464464     par l'évaluation d'expressions scalaires si nécessaire). Une des 
     
    513513    avance sur la prochaine ligne d'une des deux tables (suivant le résultat de 
    514514    la comparaison), et vérifie à nouveau la correspondance. Éventuellement, 
    515     l'un des sous-plans est épuisé et le n&oelig;ud <literal>MergeJoin</literal> renvoie 
     515    un des sous-plans est épuisé et le n&oelig;ud <literal>MergeJoin</literal> renvoie 
    516516    NULL pour indiquer qu'il n'y a plus de lignes jointes à former. 
    517517   </para>