Différences

Ci-dessous, les différences entre deux révisions de la page.

--- store_data_safely:an_intro_to_sqlite [2013/09/30 21:36] – [9] fredphil91
+++ store_data_safely:an_intro_to_sqlite [2013/10/20 12:16] (Version actuelle) – andre_domenech
@@ Ligne 25: / Ligne 25: @@
 Avec notre base de données relationnelle, nous voulons :
-• des structures de données complexes
+• des structures de données complexes ;
-• la facilité d'utilisation
+• la facilité d'utilisation ;
-• un accès simple à partir de n'importe quel langage de programmation
+• un accès simple à partir de n'importe quel langage de programmation ;
-• des instructions de base de données dans une langue proche de l'anglais
+• des instructions de base de données dans une langue proche de l'anglais ;
 • l'atomicité — si une transaction effectue plusieurs mises à jour de plusieurs fichiers, soit elle exécute toutes les mises à jour (si elle réussit), soit aucune mise à jour (si elle échoue).
-Heureusement (pour nous), la base de données relationnelle a été inventé il y a quelque temps (1970), avec un langage simple, le « langage structuré de requêtes» ou SQL, avec lequel on la contrôle et on y accède. Toutes les versions de SQL sont largement standardisées, donc il suffit de l'apprendre une seule fois.
+Heureusement (pour nous), la base de données relationnelle a été inventée il y a quelque temps (1970), avec un langage simple, le « langage structuré de requêtes » ou SQL, avec lequel on la contrôle et on y accède. Toutes les versions de SQL sont largement standardisées, donc il suffit de l'apprendre une seule fois.
 Un exemple d'instruction SQL simple (pour insérer des données dans une base de données) :
@@ Ligne 47: / Ligne 47: @@
 Hopefully, you use Firefox as your browser, as you need to install an extension (SQLite Manager 0.7.7) in order to load a full GUI interface which will allow for prompting, execution and testing of your SQL. Once you like what you see, you can transfer the SQL statements to your favourite programming language, which could be anything from BASH to BASIC.**
-Une commande SQL commence par un verbe, éventuellement suivi de plusieurs qualificatifs, et se termine toujours par un point virgule. J'ai suivi une convention commune en écrivant les mots-clés SQL en majuscules.
+Une commande SQL commence par un verbe, éventuellement suivi de plusieurs qualificatifs, et se termine toujours par un point virgule. J'ai suivi une convention commune en écrivant les mots clés SQL en majuscules.
 Outre l'aspect zéro configuration de SQLite, il y a un avantage supplémentaire pour le néophyte SQL : Firefox utilise SQLite pour gérer les caches internes, les signets, l'historique, etc. Et donc Firefox a jugé utile d'écrire une extension graphique qui facilite grandement le prototypage et la création de votre propre base de données SQLite.
@@ Ligne 71: / Ligne 71: @@
 Pour ajouter la bonne extension pour Firefox :
-• dans Firefox, cliquez sur le menu Outils > Modules complémentaires
+• dans Firefox, cliquez sur le menu Outils > Modules complémentaires ;
-• dans la boîte de recherche, saisissez SQLite Manager, vous devriez voir une entrée
+• dans la boîte de recherche, saisissez SQLite Manager, vous devriez voir une entrée ;
 • cliquez dessus et vous devriez voir une boîte de dialogue vous demandant de confirmer votre décision.
 Vous devrez alors redémarrer Firefox pour que cela prenne effet.
-Nous sommes maintenant prêts à démarrer — mais nous devrions faire un peu de conception de base de données avant de plonger.
+Nous sommes maintenant prêts à démarrer, mais nous devrions faire un peu de conception de base de données avant de plonger.
-Une base de données SQL a une structure très simple : elle consiste en un certain nombre de table qui ressemblent beaucoup à des feuilles de calcul ; elles ont un nombre prédéfini de colonnes (défini lors de la création de la table), et un nombre illimité de lignes.
+Une base de données SQL a une structure très simple : elle consiste en un certain nombre de tables qui ressemblent beaucoup à des feuilles de calcul ; elles ont un nombre prédéfini de colonnes (défini lors de la création de la table), et un nombre illimité de lignes.
-Il n'y a effectivement aucun étiquettes de ligne ; nous utilisons les données elles-mêmes pour mettre en relation une ligne de données d'une table à une ligne de données dans une autre table. Il n'y a aucune limite au nombre de tables — même si le nombre de tables devient rarement très grand.
+Il n'y a effectivement aucune étiquette de ligne ; nous utilisons les données elles-mêmes pour mettre en relation une ligne de données d'une table à une ligne de données dans une autre table. Il n'y a aucune limite au nombre de tables, même si le nombre de tables devient rarement très grand.
 ====== 5 ======
@@ Ligne 95: / Ligne 95: @@
 I've tried to follow a simple naming convention:- to prefix table names with 'T', column names are in lower-case, and SQL statements are in upper-case.**
-Cela soulève probablement la question de la performance lorsqu'on travaille sur de grandes bases de données. Cela ne fait pas que patiner parmi des quantités de données (même si cela peut arriver avec de mauvaises conceptions). Dans les coulisses, SQL maintient un certain nombre d'index, certains créés automatiquement et certains facultativement créé par l'utilisateur. De nombreuses opérations de base de données sont simplement des opérations sur ces index efficaces.
+Cela soulève probablement la question de la performance lorsqu'on travaille sur de grandes bases de données. Cela ne fait pas que patiner parmi des quantités de données (même si cela peut arriver avec de mauvaises conceptions). Dans les coulisses, SQL maintient un certain nombre d'index, certains créés automatiquement et certains facultativement créés par l'utilisateur. De nombreuses opérations de base de données sont simplement des opérations sur ces index efficaces.
-Il est important de souligner qu'une base de données SQLite est stockée comme un seul grand fichier — ce qui rend les sauvegardes (très important) une tâche particulièrement facile.
+Il est important de souligner qu'une base de données SQLite est stockée comme un seul grand fichier, ce qui rend, concernant les sauvegardes (très important), une tâche particulièrement facile.
 L'application
@@ Ligne 120: / Ligne 120: @@
 Nous allons créer quatre tables :
-Tetudiant (une ligne par élève)
+Tetudiant (une ligne par élève).
-Tadresse (une ligne par ligne d'adresse pour chaque élève)
+Tadresse (une ligne par ligne d'adresse pour chaque élève).
-Tnom_examen (une ligne pour chaque série d'examens - une liste des titres d'examens)
+Tnom_examen (une ligne pour chaque série d'examens - une liste des titres d'examens).
-Texamens (une ligne par étudiant et par examen passé)
+Texamens (une ligne par étudiant et par examen passé).
-Notez que nous aurions pu stocker l'adresse dans le tableau Tetudiant dans un nombre prédéfini de champs — mais combien ? Il y a forcément quelqu'un qui aura besoin de plus de lignes pour son adresse que ce que nous avions prévu.
+Notez que nous aurions pu stocker l'adresse dans le tableau Tetudiant dans un nombre prédéfini de champs, mais combien ? Il y a forcément quelqu'un qui aura besoin de plus de lignes pour son adresse que ce que nous avions prévu.
 Ce processus par lequel un champ extensible est déplacé dans une table secondaire est un exemple de « normalisation » et est une caractéristique importante de la conception de base de données.
@@ Ligne 143: / Ligne 143: @@
 So it's now time to create our first table. In practice, it's a good idea to set out your tables on paper before entering them into the computer as there is rarely an absolutely “correct” way to design these things.**
-Tout d'abord, nous devons créer notre base de données, il est donc temps de lancer Firefox, et de cliquer sur le menu Outils > SQLite Manager
+Tout d'abord, nous devons créer notre base de données, il est donc temps de lancer Firefox, et de cliquer sur le menu Outils > SQLite Manager.
-Vous verrez alors un écran plutôt clairsemé ; choisissez Base de données dans le menu et cliquez sur Nouvelle base de données:-
+Vous verrez alors un écran plutôt clairsemé ; choisissez Base de données dans le menu et cliquez sur Nouvelle base de données : - Nous allons appeler notre base de données « Examen », saisissez Examen dans la boîte de dialogue — le système ajoutera .sqlite à la fin et vous demandera de choisir un dossier pour la mettre —  je vous suggère de choisir votre répertoire personnel.
-Nous allons appeler notre base de données « Examen », saisissez Examen dans la boîte de dialogue — le système ajoutera .sqlite à la fin et vous demandera de choisir un dossier pour la mettre —  je vous suggère de choisir votre répertoire personnel.
 Cela nous donne un écran initial d'aspect assez compliqué (ci-dessus).
@@ Ligne 166: / Ligne 165: @@
 So now we have a properly formatted table, but it still has to be filled with data.**
-Tetudiant aura quatre colonnes (celles-ci sont parfois appelés champs).
+Tetudiant aura quatre colonnes (celles-ci sont parfois appelées champs).
-Cette liste montre les principales opérations que nous pouvons faire sur les tables — (Drop signifie supprimer une table en langage SQL).
+Cette liste montre les principales opérations que nous pouvons faire sur les tables (Drop signifie supprimer une table en langage SQL).
 Nous voulons créer une table ; faisons-le grâce au formulaire qui sert à définir notre table (ci-dessus).
-SQLite est différent des autres bases de données SQL en ce sens qu'il n'y a que quelques classes de données différentes (entier, réel, texte, null, BLOB); aucune taille n'est mentionné car SQLite va utiliser autant d'espace que nécessaire. Un BLOB (« Binary Large Object ») est une collection de données binaires stockées comme une seule entité.
+SQLite est différent des autres bases de données SQL en ce sens qu'il n'y a que quelques classes de données différentes (entier, réel, texte, null, BLOB) ; aucune taille n'est mentionnée car SQLite va utiliser autant d'espace que nécessaire. Un BLOB (« Binary Large Object ») est une collection de données binaires stockées comme une seule entité.
-Il faut confirmer que nous voulons vraiment créer cette table — et on voit l'instruction SQL qui permet d'atteindre cet objectif :
+Il faut confirmer que nous voulons vraiment créer cette table, et on voit l'instruction SQL qui permet d'atteindre cet objectif :
 Maintenant, nous avons donc un tableau bien formaté, mais il doit encore être rempli de données.
@@ Ligne 189: / Ligne 188: @@
 id_etudiant mérite quelques explications ; nous l'avons décrit comme la « clé primaire », que nous avons réglée comme étant unique. Ici la clé id_etudiant est utilisée comme une référence à l'information de chaque étudiant dans cette table et dans d'autres. En spécifiant la propriété « Unique », la base de données refusera toute tentative visant à ajouter une ligne avec une valeur id_etudiant en double.
-Les clés primaires peuvent être constituées de plus d'une colonne — par exemple, nous pourrions insister pour que la combinaison (nom, prénom) soit notre clé primaire, mais cela interdirait d'inscrire deux étudiants avec la même combinaison nom/prénom. Chaque clé primaire oblige SQLite à maintenir un index.
+Les clés primaires peuvent être constituées de plus d'une colonne - par exemple, nous pourrions insister pour que la combinaison (nom, prénom) soit notre clé primaire, mais cela interdirait d'inscrire deux étudiants avec la même combinaison nom/prénom. Chaque clé primaire oblige SQLite à maintenir un index.
 C'est habituel, mais pas obligatoire, que la clé primaire ait le mot-clé « Unique ».
-Bien que nous ayons mentionné les clés primaires, ce ne sont pas les seuls types de clé à considérer. Il convient de mentionner qu'il existe des « clés étrangères » et nous donnerons un exemple de leur utilité plus tard.
+Bien que nous ayons mentionné les clés primaires, ce ne sont pas les seuls types de clés à considérer. Il convient de mentionner qu'il existe des « clés étrangères » et nous donnerons un exemple de leur utilité plus tard.
 ====== 10 ======
@@ Ligne 204: / Ligne 203: @@
 However, entering data one line at a time will lead to very poor database performance. Because we didn't specify how many SQL statements form a logical transaction unit, SQLite assumes the single  INSERT statement is an entire transaction. The system needs to lock the database against update, check there isn't a pre-existing row with the same unique key, write the data row, and flush the data to the disk to ensure the integrity of the database. All this activity is probably going to require a couple of rotations of the disk drive. We gain “atomicity” (a row is never partially written) but suffer a large performance penalty in disk-wait time.**
-Nous pouvons maintenant inscrire des étudiants (un à la fois). Le collège a décidé que l'id_etudiant doit être imprimé sur tous les documents, et sera composé d'une lettre suivie de sept chiffres. C'est une contrainte importante qui devrait (et pourrait être) contrôlée par la base de données. Cependant, pour des raisons de simplicité, nous supposerons qu'il est manipulé correctement par le programme utilisateur.
+Nous pouvons maintenant inscrire des étudiants (un à la fois). Le collège a décidé que l'id_etudiant doit être imprimé sur tous les documents et sera composé d'une lettre suivie de sept chiffres. C'est une contrainte importante qui devrait (et pourrait être) contrôlée par la base de données. Cependant, pour des raisons de simplicité, nous supposerons qu'il est manipulé correctement par le programme utilisateur.
 Sélectionnez la table Tetudiant et choisissez l'option Ajouter :
@@ Ligne 210: / Ligne 209: @@
 Après avoir entré vos données, le système vous montrera l'instruction SQL appropriée pour ajouter une ligne.
-Toutefois, saisir des données ligne par ligne mènera à de très mauvaises performances de la base de données. Comme nous n'avons pas précisé combien de requêtes SQL forment une transaction logique, SQLite suppose que la seule instruction INSERT est une transaction complète. Le système doit verrouiller la base de données contre les mises à jour, vérifier qu'il n'y a pas une ligne préexistante avec la même clé unique, écrire la ligne de données, et forcer l'écriture des données sur le disque pour assurer l'intégrité de la base de données. Toute cette activité va probablement nécessiter quelques rotations du disque. Nous gagnons « l'atomicité » (une ligne n'est jamais partiellement écrite) mais souffrons d'une grande pénalité de performance en temps d'attente disque.
+Toutefois, saisir des données ligne par ligne mènera à de très mauvaises performances de la base de données. Comme nous n'avons pas précisé combien de requêtes SQL forment une transaction logique, SQLite suppose que la seule instruction INSERT est une transaction complète. Le système doit verrouiller la base de données contre les mises à jour, vérifier qu'il n'y a pas une ligne préexistante avec la même clé unique, écrire la ligne de données et forcer l'écriture des données sur le disque pour assurer l'intégrité de la base de données. Toute cette activité va probablement nécessiter quelques rotations du disque. Nous gagnons « l'atomicité » (une ligne n'est jamais partiellement écrite) mais souffrons d'une grande pénalité de performance en temps d'attente disque.
 ====== 11 ======
@@ Ligne 225: / Ligne 224: @@
 We can enter any reasonable number of statements (thousands) that make sense—covering multiple tables and various operations. When we reach the COMMIT statement, the database can be considered to have been properly updated. Alternatively, if an error occurs part way through (or we issue the ROLLBACK command), the database is placed back into the state it was in before we started our transaction.**
+La solution consiste à effectuer un certain nombre de mises à jour de base de données comme une seule transaction logique. Nous faisons simplement un peu plus de travail et passons moins de temps d'attente des réponses disques.
+Nous marquons le début et la fin de la transaction avec des instructions SQL :
+BEGIN TRANSACTION;
+...
+...
+COMMIT;
+Nous pouvons entrer n'importe quel nombre raisonnable d'instructions (quelques milliers) qui forment un tout, couvrant plusieurs tables et diverses opérations. Lorsque nous atteignons l'instruction COMMIT, on peut considérer que la base de données a été correctement mise à jour. Par ailleurs, si une erreur se produit à mi-chemin (ou que nous saisissons la commande ROLLBACK), la base de données est replacée dans l'état où elle était avant que nous ne commencions notre transaction.
 ====== 12 ======
@@ Ligne 241: / Ligne 250: @@
 This is unexpected—but it turns out that Firefox always arranges for invisible BEGIN and COMMIT instructions to be inserted into any SQL that is run. The error (correctly) says that you can't nest transactions.**
+Ajoutons donc un peu plus d'étudiants (nous savons que nous voulons exécuter du SQL et la « manipulation de données » semble la plus appropriée).
+Nous obtenons comme invite :
+INSERT INTO nomTable [(liste-colonnes)] VALUES(liste-valeurs)
+Compte tenu de notre tentative réussie avec une seule ligne, il semble raisonnable d'essayer de coller le morceau de code SQL suivant dans la case « Exécuter le SQL ». C'est assez long, mais c'est juste un morceau de code répétitif (ci-dessus à droite).
+Un de ces noms est une vraie personne (ci-dessus).
+Cependant, lorsque nous tentons d'exécuter ce morceau de SQL, nous obtenons :
+C'est inattendu — mais il s'avère que Firefox s'arrange toujours pour placer des instructions BEGIN et COMMIT invisibles dans n'importe quel code SQL exécuté. L'erreur indique (correctement) que vous ne pouvez pas imbriquer des transactions.
+**cadre orangé en haut de la page 18 :**
+INSERT INTO "Tetudiant" VALUES('L6181072','Claire','Johnson','J');
+INSERT INTO "Tetudiant" VALUES('J2456312','Charles','Williams',NULL);
+INSERT INTO "Tetudiant" VALUES('M1234700','Joan','Jones','A');
+INSERT INTO "Tetudiant" VALUES('K1348221','Dennis','Brown','');
+INSERT INTO "Tetudiant" VALUES('J9274173','Linda','Moore','S');
+INSERT INTO "Tetudiant" VALUES('L4522786','Percy','Taylor','ABC');
+INSERT INTO "Tetudiant" VALUES('L3665921','Janet','Anderson',NULL);
+INSERT INTO "Tetudiant" VALUES('M2287567','Carmen','Garcia','G');
+INSERT INTO "Tetudiant" VALUES('L7234219',NULL,'Martinez','');
+INSERT INTO "Tetudiant" VALUES('J8445578','Edward','Montagu-Stuart-Wortley-Mackenzie',NULL);
 ====== 13 ======
@@ Ligne 250: / Ligne 284: @@
 So far, we have managed to create just one table. It is only when we have several tables that we can map the relationships between them. You will be pleased to learn that the Firefox add-on allows you to import an initial data load if you have appropriate data available as CSV, XML or SQL source; it is also possible to export a table to these file types too. We still need to write the SQL statements to create the tables, but we can import our base data from spreadsheet(s).**
+Aucun langage de programmation ne ferait jamais ça à votre place ; dans une situation réelle, vous voulez intercepter les erreurs, et soit les corriger, soit simplement les accepter comme des erreurs qui ne sont pas suffisamment graves pour provoquer l'échec d'une transaction.
+Dans ce cas, nous supprimons simplement les instructions BEGIN et COMMIT et cela fonctionne parfaitement. Il existe une commande SQL très simple pour afficher toutes les lignes et toutes les colonnes d'une table, et nous allons l'exécuter pour prouver que notre table contient les « bons trucs » (la page suivante, en haut à gauche).
+Jusqu'à présent, nous avons réussi à créer une seule table. Ce n'est que lorsque nous avons plusieurs tables que nous pouvons cartographier les relations entre elles. Vous serez heureux d'apprendre que le module Firefox vous permet d'importer des données initiales si vous les avez au format CSV, XML ou code source SQL ; il est également possible d'exporter une table vers ces types de fichiers. Il faut quand même écrire les instructions SQL pour créer les tables, mais nous pouvons importer nos données depuis une feuille de calcul.
 ====== 14 ======
@@ Ligne 263: / Ligne 302: @@
 Since it would be meaningless to allow the entry of the address of someone who is not in the Tstudent table, we need to prevent this. This kind of problem is described as a “referential integrity issue,” and it could be prevented by relevant program coding. However, the problem is really intrinsic to our database design, and a database with dozens of tables would suffer many more referential integrity issues.**
+Pour Tadresse nous allons spécifier les colonnes comme suit :
-====== 15 ======
+Notez que nous aurions pu spécifier deux colonnes pour notre clé primaire et la commande SQL correspondante  serait :
-**The solution lies in entering the data rules into the database, so that the database can enforce data integrity (note that although the same name of student_id was used in both the Tstudent and Taddress tables, this doesn't mean that there is any implicit connection between the two tables).
-This is the situation alluded to earlier of a “foreign key”—here we would want any attempt to update Taddress to check that the student_id already exists in Tstudent. We can think of Tstudent as being the “parent” whilst the corresponding multiple address rows are “child” entries. Potential problems could also happen if we were to delete a row from the parent, but we can instruct the database to automatically delete all the child entries.
-Unfortunately, the Firefox GUI does not support the generation of SQL for foreign keys. Furthermore, it actually has foreign key supported switched off (by default) this is easily fixed by telling Firefox to run a command to enable foreign keys!
-It is important to type the PRAGMA foreign_keys=ON; correctly, and press save. You need to do this only once for each database you create, as future connections to the database will automatically run this PRAGMA command.**
-====== 16 ======
-**The correct syntax for the foreign key specification can be rather complicated. With a little practice, this is straightforward; the following will fix the situation:
-DROP TABLE "Taddress" ; delete the existing table and data...
-CREATE TABLE "Taddress" ("student_id" CHAR NOT NULL ,"line_no" INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL ,"address" CHAR, FOREIGN KEY("student_id") REFERENCES Tstudent ("student_id") ON DELETE CASCADE);
-This will cause updates to check that the FOREIGN KEY("student_id") (in Taddress) REFERENCES (matches) in the table Tstudent ("student_id" column). The ON DELETE CASCADE phrase will cause any deletion of a student in the parent (Tstudent) to delete all relevant instances from Taddress.**
-====== 17 ======
-**We can summarise the major constraints we can place on a column:
-• NOT NULL
-• UNIQUE
-• PRIMARY KEY
-• FOREIGN KEY
-• CHECK e.g. CHECK(price > 0)
-• DEFAULT (the value to be used if none is supplied)
-We can try and add an address line for a non-existent student:-
-Note that only two input parameters are needed
-This gives an error message—foreign key constraint failed.
-An attempt to add a valid student will succeed.**
-====== 18 ======
-**We don't really care whether the line number of the address is 1, 2, 3, … or not—just that it is increasing. We have arranged for the database to do it and save some work in our program.
-A simple example (in Python) of adding just a few address lines would be:
-Note that the interface converts a Python “None” into an SQL “Null”, there is no error handling, and the address line sequence number is generated (correctly) by the database.
-We now need to create a new, super simple, table which will be a “codes file”; it associates exam codes with their titles. Since it's so simple, we can just type it into the “Execute SQL” area without any prompting.
-CREATE TABLE Texam_name (exam_id CHAR PRIMARY KEY NOT NULL UNIQUE, exam_title CHAR);
-Because we have the data available, we shall load the initial data from a CSV file (created from a spreadsheet):**
-====== 19 ======
-**We now have a number of tables and we are in a position to use one of the most powerful features of SQL—when we combine two or more tables together. To do this we use the JOIN keyword. There are two main varieties of JOIN available – by far the most common type of JOIN is a matching columns JOIN (technically an INNER JOIN). You can guess the name of the other kind of JOIN!
-When specifying our JOIN, a problem that sometimes occurs is that we have used the same name for a column in two tables – but perhaps it has different meanings – in which case we need to qualify the column name by table name. As an example:
-SELECT surname, forename, address FROM Tstudent AS S
-        JOIN Taddress AS A                                            	ON S.student_id = A.student_id;
-(The multiple lines are purely for readability), we enter this into the “execute SQL” section:- Note the optional temporary renaming of the tables to single letter names, purely so the full qualification of field names is abbreviated. We don't have much data in our database, so it looks like that shown below.**
-====== 20 ======
-**It happens frequently that we make a habit of making up new names for the same thing, so in fact our student_id means the same thing in the two tables. As a shortcut we have the idea of a “NATURAL JOIN”—where any matching names are assumed to be required to be matched; so an equivalent to the previous JOIN is:
-SELECT surname, forename, address FROM Tstudent
-                          NATURAL JOIN Taddress;
-Note that a NATURAL JOIN can give unexpected results if extra columns are added to the tables at a later date.
-If we expect to want to use our address list periodically, then we should create a View (using our SELECT statement above). There is no overhead in doing so, since it is just an instruction on how to view existing tables. However, it is important to realize that for the same reason, only tables can be updated—views are just a reflection of the current state of the tables; the data in views cannot be updated.
-We can also create joins which are a JOIN of a table with itself, to create Views of a single table—perhaps to hide a particularly complex piece of SQL. It's also possible to join more than two tables in one statement—but then things tend to get complicated!**
-====== 21 ======
-**If we have a very big database—many thousands of rows in several tables—performance will suffer. In this case, we should look at how we are using our database, especially with respect to JOINs, and specify the Index → Create index option. This is likely to speed up queries, at a small penalty for database updates (we have to maintain each additional index).
-The last major feature that can be used is the TRIGGER statement – where it is desirable that some database event should 'trigger' a sequence of actions. This is really a rather advanced topic and I refer you elsewhere!
-We still have one last table to construct—the one that links the students with their exams.
-Texams	student_id	exam_id	score
-The exam score will be zero if they have not sat the exam yet. To access the score, we need the combination of student_id and exam_id to be our unique (primary key). This is a slightly tricky case, because we don't allow a student to take the same exam twice, but the data structure means that we need to accept duplicate student_id's and duplicate exam_id's, but reject any combinations of the two which are not unique. This is a situation where a composite primary key has the effect we want.**
-====== 22 ======
-**So Firefox produces:
-CREATE TABLE "Texams" ("student_id" CHAR NOT NULL, "exam_id" CHAR NOT NULL, "score" INTEGER DEFAULT 0, PRIMARY KEY ("student_id", "exam_id"))
-We should really declare student_id to be a foreign key so that it is validated against Tstudent and similarly exam_id should be a foreign key so that it is validated against Texam_name. So we delete (with DROP Texams) and execute the following SQL; as you can see, it is effectively similar to our previous encounter with foreign keys.
-CREATE TABLE "Texams" ("student_id" CHAR NOT NULL, "exam_id" CHAR NOT NULL, "score" INTEGER DEFAULT 0,
-CHECK (score >= 0),
-PRIMARY KEY ("student_id", "exam_id"),
-FOREIGN KEY("student_id") REFERENCES Tstudent ("student_id"),
-FOREIGN KEY("exam_id") REFERENCES Texam_name ("exam_id"));
-(Actually, this is not quite correct as SQLite allows character values to be stored in numeric columns—so the CHECK statement would not work properly; we could fix this with a more complicated CHECK statement—but it wouldn't add anything to the readability. So we will leave it alone).**
-====== 23 ======
-**We can enter all of the test cases using INSERT, and they should all behave properly.
-With our last table we are in a position to do something typical. The college has a few rather arbitrary rules, which change from time to time, so they don't really need to be enforced by the database. For example: “No student can enroll for M829, without achieving a pass in M823 previously”. This is easy to do in SQL with a little bit of decision in a program.
-As a slight variation, I've supplied a version that runs in a terminal screen; it could easily be converted to a BASH script. Many programs can have the database open, concurrently.**
-====== 24 ======
-**jeremy@HECTOR:~$ # An example where student K1001001 wants to enroll on M829
-jeremy@HECTOR:~$ sqlite3  Exam.sqlite       # Open database
-SQLite version 3.7.9 2011-11-01 00:52:41
-Enter ".help" for instructions
-Enter SQL statements terminated with a ";"
-sqlite> SELECT count(*) FROM Texams WHERE ("student_id" = "K1001001" AND
-   ...> "exam_id" = "M823" AND "score" >= 40 );
-sqlite> INSERT INTO Texams VALUES("K1001001", "M829", 0);
-sqlite> .exit
-jeremy@HECTOR:~$
-The SELECT count(*) … statement is an example of one of the many built-in “aggregate” functions – here the number of rows that meet the conditions in the WHERE conditional, in this case a value of '1' is returned. So we can add a row (with a score of zero) for M829.**
-====== 25 ======
-**I shall give a number of references for more advanced use; but even if you want only a single keyed file or two—perhaps for an address book—a database is a big advance over some complex coding solution.
-References:
-http://www.sqlite.org/docs.html	- The full reference; not a tutorial.
-http://zetcode.com/databases/sqlitetutorial/ - A very concise SQL tutorial.
-http://zetcode.com/db/sqlitepythontutorial/ - Python.
-http://zetcode.com/databases/sqlitephptutorial/ - PHP version.
-http://zetcode.com/db/sqliteperltutorial/ - Perl.
-http://zetcode.com/db/sqliteruby/ - Ruby.
-http://zetcode.com/db/sqlitecsharp/ - C#.
+CREATE TABLE "Tadresse" ("id_etudiant" char NOT NULL UNIQUE, ENTIER "numero_ligne" NOT NULL UNIQUE, "adresse" CHAR, PRIMARY KEY ("id_etudiant", "numero_ligne"));
-http://zetcode.com/db/sqlitevb/ - Visual Basic.
+Toutefois, nous avons choisi d'utiliser une fonctionnalité de SQLite, puisque nous n'avons qu'une seule colonne de clé primaire et qu'elle est de type entier, nous pouvons demander qu'elle soit auto-incrémentée à chaque écriture dans la table. Vous avez sans doute remarqué qu'une colonne (appelée rowid) est automatiquement insérée dans chaque ligne d'une table ; en utilisant l'auto-incrémentation, nous obtenons une suite ascendante de numéros de lignes (éventuellement avec des écarts entre deux).
-http://en.wikipedia.org/wiki/List_of_relational_database_management_systems - general interest only.**
+Comme il serait absurde de permettre de saisir l'adresse de quelqu'un qui n'est pas dans la table Tetudiant, nous devons empêcher cela. Ce genre de problème est décrit comme une « question d'intégrité référentielle », et il pourrait être évité par une programmation adaptée. Cependant, le problème est vraiment intrinsèque à ma conception de notre base de données, et une base de données avec des dizaines de tables souffrirait de nombreux problèmes d'intégrité référentielle de ce style.
+À suivre...