[..] Comment procéder pour créer une BDD?

[labougie]

Bonjour,

Le projet est à mes yeux génial, et, mérite que je le pousse au bout.
Mais je suis loin de maîtriser le sujet

Je souhaite créer une Bdd en partant D'autoit pour la saisie, puis ensuite exploiter les résultats avec autoit.

Le but de cet outil est de gérer une base contenant des propriétaires, des locataires, des prospects.

Une liaison doit être faite entre le proprio et ses biens, mais aussi avec les locataires.

exemple

Jean / proprio / Studio / T4 / T3 / Maison F5 / Maison F4
les locataires A B C D

A => studio
B => Maison F5
C => T4
D => T3

Donc si je clique ou sélectionne "Jean"
Je dois avoir:

• Le nom du locataire
• Les coordonnées de ce dernier (ou un accès rapide à ces dernières)
• le bien qu'il loue
• La liste des biens restant à louer
• A défaut la liste des biens déjà loués

Je dois aussi pouvoir saisir le nouveau proprio ainsi que ces biens, mais aussi les futurs locataires et par conséquent nourrir le BDD.

Etant encore profane, je ne trouve pas comment:

• Organiser les tâches
• Les définir, liaisons entre elles et surtout éviter la redondance
• Quels outils choisir
• Le tout pour un utilisateur final ultra novice (qui donc ne devra se contenter que de cliquer et remplir les champs pour que cela fonctionne)

J'ai préparé un bout de code pour différents Gui avec des onglets, mais je ne sais pas comment m'organiser pour cette BDD.

labougie

Masque de saisie

► Afficher le texte

Code : Tout sélectionner

 #include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>

$Version = "Béta test"

$GUI1 = GUICreate("Projet Célia by © Labougie      "& $Version, 680, 600, -1, -1) ; Création de la GUI1
$Lb1 = GUICtrlCreateLabel("Masque de saisie", 150, 10, 200, 24) ; Création du label1
GUICtrlSetFont(-1, 12, 800, 0, "MS Sans Serif") ; Mise en gras du texte du contrôle précédent (Label1)
GUISetBkColor(0x00E0FFFF)

; ########### Création Propriétaire
Global $Group1 = GUICtrlCreateGroup("Identification Propriétaire", 10, 40, 659, 250) ;création d'un cadre dans le Gui

$lblpp11 = GUICtrlCreateLabel ("Nom", 18, 65, 30, 20)
Global $Input11 = GUICtrlCreateInput("", 18, 80, 90, 20)

$lblpp12 = GUICtrlCreateLabel("Prénom", 112, 65, 40, 50)
Global $Input12 = GUICtrlCreateInput("", 112, 80, 90, 20)

$lblpp13 = GUICtrlCreateLabel("Adresse", 212, 65, 80, 30)
Global $Input13 = GUICtrlCreateInput("", 212, 80, 150, 20)

$lblpp14 = GUICtrlCreateLabel("Code Postal", 382, 65, 80 ,30)
Global $input14 = GUICtrlCreateInput("", 382, 80, 90, 20)

$lblpp15 = GUICtrlCreateLabel("Ville", 482, 65, 80 ,30)
Global $input15 = GUICtrlCreateInput("", 482, 80, 90, 20)

$lblpp16 = GUICtrlCreateLabel("Téléphone Fixe", 18, 105, 80 ,30)
Global $input15 = GUICtrlCreateInput("", 18, 120, 90, 20)

$lblpp17 = GUICtrlCreateLabel("Téléphone Portable", 112, 105, 100 ,30)
Global $input15 = GUICtrlCreateInput("", 112, 120, 90, 20)

$lblpp17 = GUICtrlCreateLabel("@ Mail", 212, 105, 80 ,30)
Global $input15 = GUICtrlCreateInput("", 212, 120, 150, 20)

; ######## Identification des biens

Global $Group2 = GUICtrlCreateGroup("Identification des biens", 10, 290, 659, 250) ;création d'un cadre dans le Gui

GUICtrlCreateCombo("", 18, 320, 80, 120)
GUICtrlSetData(-1, "Location|Vente", "Location"); default Location
GUICtrlCreateCombo("", 100, 320, 80, 120)
GUICtrlSetData(-1, "Appart|Maison", "Appart"); default Appart
GUICtrlCreateCombo("", 182, 320, 80, 120)
GUICtrlSetData(-1, "Studio|T1|T2|T3|T4|T5|T6|T7", "Studio"); default Studio
GUICtrlCreateCombo("", 264, 320, 80, 120)
GUICtrlSetData(-1, "Electricité|Gaz|Fuel|Mixte", "Electricité"); default Electricité

$lblid1 = GUICtrlCreateLabel("Adresse", 346, 305, 80, 30)
Global $Input13 = GUICtrlCreateInput("", 346, 320, 130, 21)

$lblid2 = GUICtrlCreateLabel("Code Postal", 480, 305, 80 ,30)
Global $input14 = GUICtrlCreateInput("", 480, 320, 80, 21)

$lblid3 = GUICtrlCreateLabel("Ville", 564, 305, 80 ,30)
Global $input15 = GUICtrlCreateInput("", 564, 320, 80, 21)

; ######## Boutons bas de page

$Btn01 = GUICtrlCreateButton("Valide", 30, 560, 65, 20) ; Création d'un bouton simple
GUICtrlSetBkColor(-1, 0xB9D1EA)

GUISetState(@SW_SHOW) ; très important pour afichier le GUI


While 1 ; Début de la boucle infinie

 $nMsg = GUIGetMsg() ; Récupération des messages GUI

    Switch $nMsg

        Case $GUI_EVENT_CLOSE
            Exit

    EndSwitch


WEnd ; Fin de la boucle infinie

 

Gui qui pourrait être un gui de présentation (idée)

► Afficher le texte

Code : Tout sélectionner

#include <GUIConstantsEx.au3>
#include <StaticConstants.au3>
#include <WindowsConstants.au3>




 $version = "Béta test"

; ########## Début de la création de la GUI 1 principal ##########



$GUI1 = GUICreate("Projet Célia by © Labougie      "& $Version, 600, 600, -1, -1) ; Création de la GUI1
$Lb1 = GUICtrlCreateLabel("Outil de recherche", 150, 10, 200, 24) ; Création du label1
GUICtrlSetFont(-1, 12, 800, 0, "MS Sans Serif") ; Mise en gras du texte du contrôle précédent (Label1)
GUISetBkColor(0x00E0FFFF)



; ########## Création groupe proprio

Global $Group1 = GUICtrlCreateGroup("Identification Propriétaire", 25, 40, 100, 250) ;création d'un cadre dans le Gui

$lbl11 = GUICtrlCreateLabel ("Nom", 30, 65, 30, 20)
Global $Input11 = GUICtrlCreateInput("", 30, 80, 90, 20)

$lbl12 = GUICtrlCreateLabel("Prénom", 30, 110, 40, 50)
Global $Input12 = GUICtrlCreateInput("", 30, 125, 90, 20)

$lbl13 = GUICtrlCreateLabel("Téléphone", 30, 155, 80, 30)
Global $Input13 = GUICtrlCreateInput("", 30, 170, 90, 20)

$lbl14 = GUICtrlCreateLabel("Ville", 30, 200, 80 ,30)
Global $input14 = GUICtrlCreateInput("", 30, 215, 90, 20)

$Btn01 = GUICtrlCreateButton("Recherche", 30, 240, 65, 20) ; Création d'un bouton simple
GUICtrlSetBkColor(-1, 0xB9D1EA)

$Btn01 = GUICtrlCreateButton("Efface", 30, 265, 50, 20) ; Création d'un bouton simple
;GUICtrlSetBkColor(-1, 0x8080ff) bleu roi
;GUICtrlSetBkColor (-1, 0x94CEDD) vert moyen

; ########## Création des onglets

$Tab1 = GUICtrlCreateTab( 130 , 70, 460, 220)

; ############################ Onglet Sélections ##########################
$TabSheet1 = GUICtrlCreateTabItem("Sélections")

; ########## 1ère Colonne
GUICtrlCreateCombo("", 140, 100, 80, 120)
GUICtrlSetData(-1, "Location|Vente", "Location"); default Location
GUICtrlCreateCombo("", 140, 130, 80, 120)
GUICtrlSetData(-1, "Appart|Maison", "Appart"); default Appart
GUICtrlCreateCombo("", 140, 160, 80, 120)
GUICtrlSetData(-1, "Studio|T1|T2|T3|T4|T5|T6|T7", "Studio"); default Studio
GUICtrlCreateCombo("", 140, 190, 80, 120)
GUICtrlSetData(-1, "Electricité|Gaz|Fuel|Mixte", "Electricité"); default Electricité

; ########## 2 ième Colonne
GUICtrlCreateCombo("", 230, 100, 100, 120)
GUICtrlSetData(-1, "-50 K€|50K€ -> 80K€|80K€ -> 100K€|100K€ -> 130K€|130K€ -> 180K€|+180K€", ""); default Rien


$Btn02 = GUICtrlCreateButton("Recherche", 140, 240, 65, 20) ; Création d'un bouton simple
GUICtrlSetBkColor(-1, 0xB9D1EA)

; ############################ Onglet Biens ##########################
$TabSheet2 = GUICtrlCreateTabItem("Biens")
$TabSheet3 = GUICtrlCreateTabItem("Locataires")
$TabSheet4 = GUICtrlCreateTabItem("Appt Libres")
$TabSheet5 = GUICtrlCreateTabItem("Maisons Libres")



GUICtrlCreateTabItem("") ; stoppe la définition des onglets


; pour recupere le nom de l'onglet  _GUICtrlTab_GetItemText($hWnd, $iIndex

; ########## Création groupe Locataire

Global $Group1 = GUICtrlCreateGroup("Identification Locataire", 25, 320, 550, 250) ;création d'un cadre dans le Gui


GUISetState(@SW_SHOW) ; très important pour afichier le GUI


While 1 ; Début de la boucle infinie

 $nMsg = GUIGetMsg() ; Récupération des messages GUI

 WinSetTitle("Projet Célia by © Labougie", "", "Projet Célia by © Labougie  _" & $version & "_  Onglet => " & GUICtrlRead($Tab1))

    Switch $nMsg

        Case $GUI_EVENT_CLOSE
            Exit

    EndSwitch


WEnd ; Fin de la boucle infinie

 

[jguinch]

A quel niveau se situe ton problème d'organisation ? Tu as déjà fait une ébauche de ta base ?

[walkson]

Bonsoir,
je te proposerais de réaliser 3 tables:
1- proprio
2- biens
3- locataires
pour la table proprio:
key proprio/nom/adresse etc...
pour la table biens:
key biens/key proprio/adresse/style/état/ etc...
pour la table locataires:
key locataire/key biens/nom/date installation/ etc...

Pour se faire, j'utiliserais Excel avec 3 sheets et pour les keys, l'adresse de la cellule A1, A2 etc...
Au niveau d'Autoit, soit 3 guis ou une gui avec 3 Tab pour création d'un nouveau proprio, bien ou locataire
Pour la recherche, soit 2 guis ou un gui avec 2 Tab pour la recherche par proprio (proprio>biens>locataire) et pour la recherche par locataire (locataire>bien>proprio), la lecture des keys permettant de passer d'une table à l'autre.
J'espère avoir été clair et t'inspirer

[mikell]

Avec la même organisation j'utiliserais plutôt comme outil une bdd SQLite, c'est très souple d'utilisation et très rapide même avec une grande quantité de données

[labougie]

Bonsoir

A quel niveau se situe ton problème d'organisation ? Tu as déjà fait une ébauche de ta base ?

Oui et non pour l'organisation de la base.
Je ne comprends pas comment lier les informations afin qu'elles s'emboitent naturellement.

C'est à dire:

Si tu tapes "Jean" (le prioprio), comment lier le fait qu'il soit le propriétaire de tel ou tel bien, mais aussi que A B C sont bien les locataires de ses biens.

Si je tape inversement, A ou B ... je dois pouvoir retrouver le propio.
Sur le même principe avec les biens, afin d'avoir une recherche la plus large possible.
L'idée me semble bien, mais est elle raisonnable, logique ou dénuée de sens pratique.

---

Bonsoir,
je te proposerais de réaliser 3 tables:
1- proprio
2- biens
3- locataires
pour la table proprio:
key proprio/nom/adresse etc...
pour la table biens:
key biens/key proprio/adresse/style/état/ etc...
pour la table locataires:
key locataire/key biens/nom/date installation/ etc...

Walkson,

Dans key tu signifies que l'onglet porte le nom de "proprio", "biens" et "locataires", n'est-ce pas?

Pour se faire, j'utiliserais Excel avec 3 sheets et pour les keys, l'adresse de la cellule A1, A2 etc...
Au niveau d'Autoit, soit 3 guis ou une gui avec 3 Tab pour création d'un nouveau proprio, bien ou locataire
Pour la recherche, soit 2 guis ou un gui avec 2 Tab pour la recherche par proprio (proprio>biens>locataire) et pour la recherche par locataire (locataire>bien>proprio), la lecture des keys permettant de passer d'une table à l'autre.

j'ai un problème de vocabulaire, pour ta démonstration, Gui => ok , mais tab => onglet ou autre chose ?
[[[En me relisant, surtout ceci => pour la table biens:
key biens/key proprio/adresse/style/état/ etc..., je crois que key n'est pas le nom de l'oglet]]]
Suis un peu perdu, pourtant cela semble simple en te lisant.
Je sais que dans ce genre de travail, le plus important, c'est la préparation (le code aussi)

---

Avec la même organisation j'utiliserais plutôt comme outil une bdd SQLite, c'est très souple d'utilisation et très rapide même avec une grande quantité de données

En supposant, que j'opte pour une base SQLite, est-ce que l'utilisateur final doit obligatoirement installer le logiciel SQLite?
Aussi, là je ne connais pas du tout cet outil, mais bon apprendre c'est du domaine du très possible.

labougie

[jchd]

Je vais tenter de répondre à quelques-unes de tes interrogations, sans ordre particulier.

a) SQLite ne demande aucune installation (outre une dll que l'on peut FileInstall-er une fois pour toute sur chaque poste), aucune configuration spécifique, aucune maintenance et peu de technicité de mise en oeuvre (comparé aux moteurs de BDD à architecture client-serveur ou [bien pire] à Excel).

b) Toute base SQLite v3 (un seul fichier) est portable sur à peu près toutes les plate-formes matériel+OS existantes sans demander une quelconque conversion. SQLite est utilisé dans les GPS, les smartphones, des routers, des robots, quasiment tous les ordinateurs personnels ou des serveurs de toute taille. La plus grosse base SQLite que je connaisse dépasse la taille très exceptionnelle de 120 To et alimente un site web fréquenté.

c) Un moteur de BdD SQL ne sert qu'à organiser le stockage et permettre un accès efficace aux données qu'il abrite. Donc on ne "tape" pas "Dupont" pour tout savoir sur la vie de ce quidam, mais on utilise des requêtes SQL pour récupérer des informations précises selon des critères précis :
select nom, prénom, no_portable, no_fixe from phonebook where nom like 'dupon%' and lower(prénom) in ('pierre', 'paul', 'jacques');


d) Tu dois avant tout te diriger vers un tutoriel SQL pour acquérir le B-A-BA des principes et du fonctionnement d'un moteur SQL. Il y en a des tonnes sur le web, dans toutes les langues.

e) Je te conseille très vivement de télécharger un outil qui va te permettre de te familiariser et d'expérimenter avec SQLite. Prend SQLite Expert en version gratuite, il fait déjà pas mal de choses. Tu pourras jouer à ta guise sans avoir à écrire une seule ligne de code AutoIt.

f) Une base SQL se compose généralement de plusieurs tables qui sont régies par des contraintes et liées entre elles par des relations 1-1, 1-N, N-1 ou N-N, le plus souvent par un mécanisme de clés étrangères (foreign keys) et de jointures. Ainsi, un bailleur peut posséder plusieurs biens (1-N), chaque locataire peut louer plusieurs biens (1-N) mais un bien donné n'a qu'un bailleur (1-1) et qu'un locataire (1-1).

g) SQL n'a rien à voir avec une feuille de calcul et l'architecture "normale" est souvent contraire à l'intuition dictée par les habitudes de programmation impérative. Dans ton contexte, il est naturel en SQL de regrouper toutes les adresses et coordonnées de contact (bailleur, bien, locataire) dans une seule table et de lier ces adresses depuis les tables bailleur, bien et locataire. Ce choix est de beaucoup préférable à celui qui consisterait à avoir des colonnes d'adresse et de contact dans chacune de ces trois tables.

h) Tu as intérêt à prévoir les cas qui dépassent le vécu habituel afin de ne pas te trouver dans une impasse après quelques temps. Un locataire doit avoir une adresse de résidence et de contact, mais ce n'est pas forcément celles d'une location.

i) Oublie le terme "onglet" dans le contexte SQL. En SQL, une clé (key) est un identifiant, souvent unique.

j) Ne te précipite surtout pas à coder quoi que ce soit. Construit et peaufine d'abord le schéma de ta base avec Expert et crée les requêtes dont tu auras besoin. Quand le tout fonctionnera comme tu le souhaites, alors seulement tu pourras commencer à coder, en finissant par l'IHM.

k) Mais avant tout, impose-toi de mettre noir sur blanc les spécifications de ta problématique et détaille au maximum les contraintes requises.

l) Ne pas mettre les informations de location dans la table locataire ! Non seulement un locataire pourrait louer plusieurs biens simultanément (ex. résidences principale et secondaire, ou encore location par une famille de leur résidence et d'un ou plusieurs studios pour leurs enfants étudiants) mais on ne pourrait pas facilement conserver un historique des locations. Ceci implique la création d'une table locations séparée, liant un locataire et un bien à des informations propre à ce contrat.

m) Je n'ai aucune idée de l'ambition de ton projet, mais il te faut viser la flexibilité maximale tout en restant raisonnable. Si tu veux gérer des prospects à qui on propose et fait visiter plusieurs biens, il peut être malin de créer une table liant les biens déjà proposés/visités pour éviter de proposer 4 fois le même T3 à une famille de 5 personnes. Il est aussi parfaitement possible de mettre sur pied une recherche sur critères, y compris géographiques, ex. "dans un rayon de 35 km autour de Tricotin les Trois Mosquées".

n) J'allais oublier un point crucial : une base SQLite doit être locale, mais supporte des accès concurrents sans problème.

Desolé pour le mur de texte et bonne digestion d'icelui !

[walkson]

Bonjour,
C'est là où on voit la différence entre le "bricoleur" et les pros
C'est vrai que l'utilisation de SQlite est plus adaptée surtout pour les recherches mais sa mise en œuvre n'est pas des plus facile...
Pour répondre à tes questions:

Code : Tout sélectionner

Global $Form1 = GUICreate("Form1", 615, 438, 192, 124)
Global $Tab1 = GUICtrlCreateTab(48, 40, 513, 369)
Global $TabSheet1 = GUICtrlCreateTabItem("proprio")
Global $TabSheet2 = GUICtrlCreateTabItem("locataire")
Global $TabSheet3 = GUICtrlCreateTabItem("biens")
GUICtrlSetState(-1,$GUI_SHOW)
GUICtrlCreateTabItem("")
GUISetState(@SW_SHOW)

Code : Tout sélectionner

      A        B         C             D
1   Key     Nom   Prénom   Adresse
2   A2  Legros    Louis    4 Rue Truc
3   A3  etc…  
Si tu utilise Excel, l'idée est qu'une table renvoie les références d'une ou plusieurs tables pour l'intermédiaire des clés
Ainsi, on pourrait avoir sur la Feuille "Biens"    
      A           B              C                          D             
1   KeyBien Key proprio  Keylocataire       Adresse
2   A2         A2               A6                   14 Rue Machin
La lecture de la ligne 2 (Feuil2) me donne le nom du proprio (Feuil1 A2) et du locataire (Feuil3 A6) pour un immeuble Rue Machin

Idéalement serait de faire (Avec Excel ou SQlite) un petit programme pour tester les liaisons et les retours de recherche avec toutes les possibilités.
(jchd explique très bien)
Sur Access 2007, il y a un exemple nommé Biens qui permets de voir à titre d'exemple l'architecture d'une BDD si tu souhaite passer par SQlite

[mikell]

Hum un bémol concernant le c) et le i) : il ne faut pas confondre ce qui se passe dans l'interface utilisateur et la manière dont les requêtes sont gérées par la bdd
Comme dab, en pratique le plus difficile n'est pas de réaliser l'interface ni d'agencer la bdd mais d'organiser proprement la communication entre les deux, à ce titre le k) est particulièrement important
Donc tu "tapes" effectivement Dupont, avec (ou pas) des onglets et c'est après pression du bouton Valider que ça passe en 'fonctionnement bdd' et que ça se corse

Concernant le m) et la recherche "dans un rayon de 35 km autour de Tricotin les Trois Mosquées" je reste quand même dubitatif, la quantité d'infos à entrer me semblant disproportionnée par rapport au résultat attendu -- un Google Maps embedded serait à la fois plus simple et plus efficace pour ce genre de truc

Pour les tutoriaux, pour m'y être frotté avec plus ou moins de bonheur je peux t'en indiquer 2 sympas et 'accessibles' quand on débute :
http://www.w3schools.com/SQL/sql_select.asp
http://www.tutorialspoint.com/sql/sql-select-query.htm

[jchd]

Oui, je voulais dire pour c) et i) que ce n'est pas du ressort de la bdd de gérer ça. C'est ce qui se passe du côté applicatif et IHM.

Pour m) je n'ai jamais dit que ça devait être fait en local, simplement que c'est parfaitement concevable de penser à ce genre de truc si le contexte le justifie. Spatialite est aussi là pour démontrer que le moteur peut très bien le faire.

Il y a aussi les tutoriels de Frédéric Brouard, mais ils sont plutôt exhaustifs et orientés "entreprise".

Pour SQLite spécifiquement, le mieux est le site de référence, en anglais.

[labougie]

Bonjour,

Merci à tous pour vos remarques constructives.

Je vais regarder tout d'abord du coté de Sqlite puis en fonction des difficultées rencontrer, sans doute ensuite vers excel, (sans oublier de regarder comme le souligne walkson l'exemple d'acces).

Mikell,
J'ai suivi ton topic de ta 1ere bdd, je prends bonne note aussi de ton second lien.
Je comprends qu'ensuite le chemin entre la base et Autoit peut sembler assez périlleux pour le novice que je suis.

Walkon,
Merci pour tes 2 exemples

Jchd,
Que de bonnes lectures. Longues mais très enrichissantes.

Le point j) est donc celui à mettre en avant.
Composer papier les liaisons entre les divers groupes puis créer la base en réel pour enfin terminer par l'interface. (Entendu pour le chemin à suivre)
Les codes indiqués plus haut sont pour montrer un principe d'utilisation, après effectivement, je pense que l'interface sera complètement revue suite à tes conseils.

Le point m)
Je retiens l'idée des prospects, sans aller jusqu'au paramètre géographique, mais j'enregistre tout de même les infos dans un coin du pc au cas ou.

La marque g) c'est pour éviter le .

Dans ton contexte, il est naturel en SQL de regrouper toutes les adresses et coordonnées de contact (bailleur, bien, locataire) dans une seule table et de lier ces adresses depuis les tables bailleur, bien et locataire.

Cette remarque est donc le point le plus important pour la conception/architecture de la base.
Mais pourquoi lier les informations ainsi?
Par soucis de recherches plus rapide?
Par recoupement plus aisé dans le traitement final avec l'interface?

Que d'excellentes infos

labougie

[jchd]

En ce qui concerne le dernier § de ton dernier post, l'idée est de normaliser la base, c'est-à-dire de respecter un certain nombre de contraintes, de plus en plus strictes selon de niveau de normalisation visé.

Pour rester simple, les idées directrices sont d'éviter au maximum la duplication d'informations dans la base et le regroupement en une même table de ce qui a la même structure et peut être différencié eventuellement par un indicateur, si besoin.

Du point de vue applicatif, cela amène par exemple à regrouper les adresses et seulement mettre l'identificateur de l'adresse dans la rangée "bien", "proprio" ou "locataire". Du coup, cela simplifie l'architecture de la base et aussi le code appli, car il n'est besoin que de valider en une seule fonction toute nouvelle adresse. Si on met des adresses dans plusieurs tables, il faudra dupliquer le code pour chacune de ces tables. Une adresse est une entité assez complexe et commune à plusieurs contexte, ce qui justifie d'en faire une sorte de "brique logicielle", du moins du point de vue stockage et accès.

Je te concocte un schéma à titre d'exemple.

[labougie]

Bonjour Jchd,

Merci pour ta préparation.

labougie