Outils pour utilisateurs
intro_histoire_numerique:modele_logique
Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révision Les deux révisions suivantes | ||
|
intro_histoire_numerique:modele_logique [2020/10/31 14:05] Francesco Beretta [Un exemple de modèle conceptuel] |
intro_histoire_numerique:modele_logique [2020/11/09 11:24] Francesco Beretta [Ajouter de nouvelles tables] |
||
|---|---|---|---|
| Ligne 12: | Ligne 12: | ||
| - | Sur ce graphique représentant le modèle conceptuel, on reconnaît les classes avec leurs propriétés, et les relations (orientées) entre les classes avec leurs cardinalités. | ||
| \\ | \\ | ||
| - | Ce modèle conceptuel permet de traiter un questionnement de base relevant de la méthode proposopographique, comprenant ces aspects: | + | Ce modèle conceptuel permet de traiter (de manière relativement simple mais efficace) un questionnement relevant de la méthode prosopographique, comprenant ces aspects: |
| * dater et localiser les naissances des personnes (afin de les afficher sur une carte) | * dater et localiser les naissances des personnes (afin de les afficher sur une carte) | ||
| * représenter les liens familiaux: parents, fratrie, jumeaux, etc. | * représenter les liens familiaux: parents, fratrie, jumeaux, etc. | ||
| + | * on utilise la classe Union qui représente la relation des parents (mariage, union libre, etc.) donnant lieu aux naissances | ||
| + | * les autres rapports de parentée sont __calculés__ à partir des unions | ||
| + | * les autres rapports de parentée ne doivent pas être renseignés en utilisant la classe union | ||
| * gérer les différentes appellations des personnes | * gérer les différentes appellations des personnes | ||
| * classifier les personnes avec une classification définie par l'utilisateur (//tags//) | * classifier les personnes avec une classification définie par l'utilisateur (//tags//) | ||
| - | * traiter les métiers et autres occupations des personnes, leur évolution dans le temps, et pouvoir les cartographier | + | * traiter les métiers et autres occupations des personnes, leur évolution dans le temps et pouvoir les cartographier |
| + | * traiter les spécialisation des métiers et leur appartenances à différents domaines. | ||
| + | |||
| + | Sur le modèle conceptuel on reconnaît les classes avec leurs propriétés et les relations (orientées) entre les classes avec leurs cardinalités. | ||
| + | |||
| + | Pour les classes qui représentent des événements, comme la naissance, union, poursuite d'une activité, ainsi que sur les appellations, une propriété 'sources' a été ajoutée permettant d'accueillir sous forme de texte l'origine précise de cette information. Si on souhaite mettre des considérations semblables pour les objets (personnes, lieux, etc.) on les ajoutera dans la propriété 'notes' qui figurera dans toutes les tables (cf. ci-dessous). Le 'sourçage' est spécifique (et virtuellement obligatoire) pour toutes les informations mettant en relation les objets, d'où une propriété explicite. | ||
| ===== Le modèle logique ou relationnel ===== | ===== Le modèle logique ou relationnel ===== | ||
| Ligne 47: | Ligne 55: | ||
| \\ | \\ | ||
| - | person(//pk_person//, name, definition, gender, death_date, __fk_birth__) \\ | + | person(//pk_person//, name, definition, gender, death_date, __fk_birth__, notes) \\ |
| - | appellation(//pk_appellation//, __pk_person__, name) \\ | + | appellation(//pk_appellation//, __pk_person__, name, sources, notes) \\ |
| - | tag(//pk_tag//, __fk_parent_tag__, name, definition) \\ | + | tag(//pk_tag//, __fk_parent_tag__, name, definition, notes) \\ |
| - | tags(//pk_tags//, __fk_person__, __fk_tag__) \\ | + | tags(//pk_tags//, __fk_person__, __fk_tag__, notes) \\ |
| - | pursuit(//pk_pursuit//, __fk_person__, __fk_occupation__, __fk_organisation__, begin_date, end_date) \\ | + | pursuit(//pk_pursuit//, __fk_person__, __fk_occupation__, __fk_organisation__, begin_date, end_date, sources, notes) \\ |
| - | organisation(//pk_organisation//, __fk_geographical_place__, name, definition) \\ | + | organisation(//pk_organisation//, __fk_geographical_place__, name, definition, notes) \\ |
| - | occupation(//pk_occupation//, name, definition) \\ | + | occupation(//pk_occupation//, name, definition, notes) \\ |
| - | specializes_occupation(//pk_specializes_occupation//, __fk_parent_occupation__, __fk_child_occupation__) \\ | + | specializes_occupation(//pk_specializes_occupation//, __fk_parent_occupation__, __fk_child_occupation__, notes) \\ |
| - | birth(//pk_birth//, date, __fk_geographical_place__, __fk_union__) \\ | + | birth(//pk_birth//, date, __fk_geographical_place__, __fk_union__, sources, notes) \\ |
| - | union(//pk_union//, __fk_union_type__, begin_date, end_date, __fk_person_1__, __fk_person_2__) \\ | + | union(//pk_union//, __fk_union_type__, begin_date, end_date, __fk_person_1__, __fk_person_2__, sources, notes) \\ |
| - | union_type(//pk_union_type//, name, definition) \\ | + | union_type(//pk_union_type//, name, definition, notes) \\ |
| - | geographical_place(//pk_geographical_place//, name, definition, longitude,latitude, __fk_geographical_place_type__) \\ | + | geographical_place(//pk_geographical_place//, name, definition, longitude,latitude, __fk_geographical_place_type__, notes) \\ |
| - | geographical_place_type(//pk_geographical_place_type//, name, definition) \\ | + | geographical_place_type(//pk_geographical_place_type//, name, definition, __fk_parent_geographical_place_type__, notes) \\ |
| + | |||
| + | **N.B.** Il est conseillé de mettre sur toutes les tables une propriété de type texte appelé 'Notes' qui servira à saisir tout type de remarque, aspect à compléter, source ou document dont est issue l'information, etc. Cette propriété n'est pas indiquée dans le modèle conceptuel pour ne pas l'alourdir mais elle figure dans le modèle logique. | ||
| + | |||
| + | \\ | ||
| ===== Création de la base de données SQLite qui implémente le modèle logique ou relationnel ===== | ===== Création de la base de données SQLite qui implémente le modèle logique ou relationnel ===== | ||
| \\ | \\ | ||
| + | Après avoir défini le modèle logique ou relationnel, on passe à la réalisation physique de la base de données, à son implémentation avec le logiciel SQLite. | ||
| + | |||
| + | |||
| + | Pour ce faire nous allons utiliser le client graphique SQLite Studio (cf. [[intro_histoire_numerique:modelisation_bases_donnees#sqlitestudio|cette page]]). | ||
| + | \\ | ||
| + | Les instructions qui suivent permettent de guider l'utilisateur dans les tout premiers pas et elles ne remplacent pas le manuel d'utilisation est disponible sur [[https://github.com/pawelsalawa/sqlitestudio/wiki/User_Manual|cette page]] qu'on doit avoir toujours sous la main. | ||
| + | |||
| + | |||
| + | ==== Création de la base de données ==== | ||
| + | |||
| + | |||
| + | Instructions: | ||
| + | |||
| + | * créer un dossier (répertoire) dans le dossier dédié au cours et l'appeler 'bases_sqlite' (sous-entendu bases de données sqlite) qui va contenir une ou plusieurs bases de données | ||
| + | * ouvrir le logiciel SQLiteStudio | ||
| + | * dans le menu //Database// ou avec le bouton correspondant activer la commande 'Add a database' | ||
| + | * choisir le type par dévaut SQLite3 | ||
| + | * appuyer sur le bouton '+' en vert | ||
| + | * entrer un nom pour la base de données (sans espaces, seulement avec des '_' entre les paroles, et sans accents), par ex. __prosopographie__ | ||
| + | * naviguer vers le dossier 'bases_sqlite' précédemment créé. | ||
| + | * appuyer sur le bouton 'Enregistrer' | ||
| + | * on revient à la boîte de dialogue 'Database', on lit le chemin vers le fichier SQLite et son nom, prosopographie.db, et on valide avec le bounton 'OK'. | ||
| + | |||
| + | La nouvelle base de données s'affiche dans la liste des bases de données à gauche. Appuyer deux fois sur elle et l'ouvrir. | ||
| + | |||
| + | \\ | ||
| + | ==== Ajouter de nouvelles tables ==== | ||
| + | |||
| + | \\ | ||
| + | Instructions: | ||
| + | |||
| + | * commencer par ajouter des tables qui n'ont pas de clés étrangères, par ex. 'geographical_place_type' | ||
| + | * click droit sur 'Tables' à gauche dans la liste des objets de la base de données et 'Create a table' | ||
| + | * insérer le nom de la table | ||
| + | * ajouter des colonnes à partir du modèle logique ou relationnel avec le bouton ajout de colonne (ligne verte au milieu), clicker pour ajouter chaque colonne: | ||
| + | * pk_geographical_place_type, data type: INTEGER, click sur case //Primary key// car ce sera la clé primaire de la table. | ||
| + | * Une colonne clé primaire de type entier (//integer//) sera autoincrémentée de 1 à n | ||
| + | * Pour des tables avec un très grand nombre de lignes utiliser le type de valeur BIGINT | ||
| + | * name, data type: VARCHAR (caractères de longueur variable, utilisable pour les labels et noms), Size: 150 (la saisie sera limitée à 150 caractères | ||
| + | * definition, data type: TEXT | ||
| + | * notes, data type: TEXT | ||
| + | * ajouter la clé étrangère vers la même table (relation réflexive de classement) | ||
| + | * la colonne s'appellera 'fk_parent_geographical_place_type' | ||
| + | * elle sera de type INTEGER | ||
| + | * on coche ensuite Foreign Key et on ouvre 'Configure' | ||
| + | * on choisit la 'Foreign table' : geographical_place_type | ||
| + | * on choisit la 'Foreign column': 'pk_geographical_place_type' | ||
| + | * on coche MATCH ce qui va introduire un contrôle automatique | ||
| + | * on applique: 'Apply' | ||
| + | * on crée la colonne | ||
| + | |||
| + | * **IMPORTANT** : sauvegarder la table en appuyant sur le bouton vert en forme de 'V' | ||
| + | * apparaît alors l'instruction SQL qui sera envoyée à la base de données et que vous pourriez aussi envoyer directement pour créer de nouvelles tables en la collant et exécutant dans 'Tools > Open SQL Editor' | ||
| + | * appuyer sur 'OK' | ||
| + | |||
| + | * créer la table 'geographical_place' avec la même méthode | ||
| + | * après avoir créé clé primaire, nom, descriptif et notes, ajouter: | ||
| + | * les champs //longitude// et //latitude// qui seront de type NUMERIC | ||
| + | * ajouter la clé étrangère vers la table 'geographical_place_type' | ||
| + | * la colonne s'appellera 'fk_geographical_place_type' | ||
| + | * elle sera de type INTEGER | ||
| + | * on coche ensuite Foreign Key et on ouvre 'Configure' | ||
| + | * on choisit la 'Foreign table' : geographical_place_type | ||
| + | * on choisit la 'Foreign column': 'pk_geographical_place_type' | ||
| + | * on coche MATCH ce qui va introduire un contrôle automatique | ||
| + | * on applique: 'Apply' | ||
| + | * on crée la colonne | ||
| + | * on n'oublie pas d'__enregistrer la nouvelle table__ ! | ||
| + | |||
| + | |||
| + | On procède ainsi pour toutes les autres tables. | ||
| + | |||
| + | * **IMPORTANT** : Traitement des **dates** | ||
| + | * dans une base de données SQLite (sqlite3) le format de DATE n'imposte pas de contrainte précise, ça peut être un chiffre ou une chaine de caractères (cf. [[https://www.w3resource.com/sqlite/sqlite-data-types.php|ces explications]]) | ||
| + | * Si on traite uniquement des dates dans l'Ére commune ou chrétienne (après Jésus-Christ) on peut utiliser la valeur VARCHAR pour les dates, en mettant une limite à 12 charactères et en utilisant le format ISO qui permet les dates tronquées et le tri de type texte: 1900-10-15, 1900-10, 1900. | ||
| + | * Si on a des dates avant l'Ère commune, deux champs sont nécessaires : année (entier avec valeur négatives possible) ; mois-jour si nécessaire (varchar) | ||
| + | * Si on a besoin de heures:minues:secondes les ajoute (dans les deux cas) après le jour, par exemple sous cette forme 1900-10-15T09-10-04 | ||
| + | |||
| + | |||
| + | A noter que on ne pourra pas créer la table 'person' ou 'birth' directement avec toutes les clé étrangères, car 'birth' dépend de 'union' qui dépend à son tour de 'person'. | ||
| + | * on créer d'abord la table 'person' | ||
| + | * on ajoute la colonne INTEGER pour la clé étrangère vers 'birth' qui sera appelée 'fk_birth' et on ne renseigne pas le lien vers la clé primaire | ||
| + | * on enregistre la table 'person' | ||
| + | * on crée ensuite 'union', puis 'birth' | ||
| + | * enfin on va modifier la table 'person' (click droit sur la table et 'Edit the table'), modifier la colonne (double-click sur la colonne) et on ajoutera la référence de la clé étrangère vers la table 'birth' | ||
| + | |||
| + | |||
| + | \\ | ||
| + | ==== Ajouter des lignes aux tables ==== | ||
| + | |||
| + | |||
| + | Pour ajouter des lignes, correspondant aux individus ou entités de cette classe, passer dans une table dans l'onglet 'Data' puis: | ||
| + | * appuyer sur plus | ||
| + | * ne rien saisir dans le champs 'pk_...' de la clé primaire qui sera rempli automatiquement | ||
| + | * ajouter un nom et une définition (par ex. pour un type de lieu) | ||
| + | * si il y a des clé étrangères et que des lignes ont été renseignées dans la table primaire se positionner dans le champs de la clé étrangère affichera la liste des entités de la table primaire (exemple de lieux et types de lieux) | ||
| + | * une fois une ligne renseignée appuyer sur ajouter une autre ligne (+) ou enregistrer (V) | ||
| + | * __ne pas oublier d'enregistrer__ chaque fois avant de quitter cette vue | ||
| + | * Rafraîchir la table avec le bouton bleu tout à gauche | ||
| + | |||
| + | ==== Ébauche de base de données ==== | ||
| + | Voici {{:intro_histoire_numerique:prosopographie.db.zip|un fichier}} qui contient les deux premières tables de la base de données, avec quelques lignes. Dézippés le fichier compressé et ouvrez le avec SQLiteStudio -> nouvelle base de donnée et ouvrir à la place ce créer la base de données (cf. [[https://github.com/pawelsalawa/sqlitestudio/wiki/User_Manual#using-existing-database|le manuel]]). | ||
intro_histoire_numerique/modele_logique.txt · Dernière modification: 2024/03/04 13:55 par Francesco Beretta
