Base de données SQL - Comment l'organiser

Bonjour,

Voilà, je viens d'installer une base SQL (express 2008) et Visual 2010 (express) sur ma machie.
Le but : et bien faire ma petite application indépendante d'excel ou acces.
(Formulaires de saisie pour le fonctionnement général, stockage dans la BDD des infos)
Mais : je suis vraiment nul en BDD; je ne comprends pas comment organiser mes tables dans la base. (je vois pas, je bloque sur la compréhension du fonctionnement et utilisation de la base)
Quelqu'un a t-il un petit conseil à me donner ?

exemple pratique simple que je voudrais débuter :
Table "Balle" = Balle_Marque et Balle_Reference ex : [speer; 1234]
Table "Cartouche" = Calibre; Calibre_Marque; LgCartoucheCIP; LgDouilleCIP; .. ex : [.222; REM;10.5;12.5]
Table "RechargementBase" = Et c'est là que je bloque .....
Cette table doit contenir des valeurs issues des tables précédentes et des valeurs propres (poids de poudre, lgDouille recoupé etc ..)
Quels sont les champs à entrer dans cette table ?
Est ce qu'il faut tous les répéter ou je peux faire des liaisons avec les tables "balle", "cartouche" etc..

Merci d'avance.

ma femme étant analyste programmeur, elle me dit de te dire cela:

mettre un identifiant dans chaque table " clé primaire"
après dans ta table souhaité, tu récupère la clé primaire.

Je te répète seulement, pour moi c'est du charabia. SI besoin, elle pourra peux être se pencher sur le problème.

matt12 a écrit:ma femme étant analyste programmeur, elle me dit de te dire cela:

mettre un identifiant dans chaque table " clé primaire"
après dans ta table souhaité, tu récupère la clé primaire.

Je te répète seulement, pour moi c'est du charabia..

Merci Matt et merci à Madame.

Je crois que les clés sont utiles pour lier des tables entre elles et (ou) accélérer les accès.
J'ai créée des tables simples (style Table_Balle = {Marque,Reference} ou Table_Cartouche={ Calibre, Marque, LgCIP ..} et je l'ai ai remplies à la main via Visual studio express. (base SQL 2008 express)
La table qui contiendra les données de rechargement devra être du style :
Table_Rechargement {Calibre, MarqueCalibre, BalleMarque, BalleReference, BallePoids, etc ... pour tous les composants}

Pour l'instant je bataille pour récupérer les valeurs contenues dans une table simple et les afficher sur 2 colonnes par exemple dans
une listBox ou Combobox sur 2 colonnes. (je n'arrive qu'à afficher qu'une colonne)

C'est pas gagné c't' affaire.
J'ai déjà galéré avec excel VBA et maintenant il faut que j'ingurgite le VB de visual studio et son interface (quifquif bourricot) et surtout les requêtes SQL
ou je suis un vrai blaireau.

je crois que je vais aller couper un peu de bois pour m'aérer les neurones...

SI besoin, elle pourra peux être se pencher sur le problème.

ça, c'est une bonne idée. Merci mais je ne voudrais pas abuser quand même .
le problème est ICI :
Le Bazar à reformater en visual studio + SQL
Pour pouvoir l'utiliser sur des machines qui n'ont pas Office. (tiens j'ai pas essayé avec open office ??)

Salut,
Je n'y connais rien en rechargement ... mais, tout dépend ce que tu veux modéliser, si UNE balle ET UNE cartouche donne UNE série d'infos, l'identifiant unique de ta table rechargement doit être une clef composée de l'id de ta table balle + l'id de ta table cartouche.

Apparement son problème n'est pas au niveau de design de la bdd, mais l'accès aux données depuis un autre logiciel.

Tu peux déjà essayer de faire les requetes SQL dans le logiciel fourni avec SQL Server.

Gaby53 a écrit:Mais : je suis vraiment nul en BDD; je ne comprends pas comment organiser mes tables dans la base.
[...]
Quels sont les champs à entrer dans cette table ?
Est ce qu'il faut tous les répéter ou je peux faire des liaisons avec les tables "balle", "cartouche" etc..

Merci d'avance.

A mon avis c'est bien une question de modélisation ...

Tu as raison. Je n'avais pas tout lu. Je me suis arreté sur

Pour l'instant je bataille pour récupérer les valeurs contenues dans une table simple et les afficher sur 2 colonnes par exemple dans
une listBox ou Combobox sur 2 colonnes. (je n'arrive qu'à afficher qu'une colonne) redevil

C'est pas gagné c't' affaire.
J'ai déjà galéré avec excel VBA et maintenant il faut que j'ingurgite le VB de visual studio et son interface (quifquif bourricot) et surtout les requêtes SQL
ou je suis un vrai blaireau. bounce

C'est vrai qu'il vaut mieux bien modéliser dès le départ pour éviter des ennuis ensuite.

bubble a écrit:Salut,
Je n'y connais rien en rechargement ... mais, tout dépend ce que tu veux modéliser, si UNE balle ET UNE cartouche donne UNE série d'infos, l'identifiant unique de ta table rechargement doit être une clef composée de l'id de ta table balle + l'id de ta table cartouche.

En fait, je voudrais reproduire l'appli excel (VBA) avec de nouveaux outils, indépendants des logiciels Office.
Grosso modo, le but est d'obtenir une base de données des "rechargements de cartouches" que l'on pratique.
En clair un rechargement est unique pour un type de cartouche ET une balle ET une poudre donnés.
A savoir que l'on ne joue pas aux apprentis sorciers en utilisant le poids de la poudre utilisée dans un rechargement pris au hasard
pour le mettre avec une cartouche de nature différente (calibre par exemple).
Les éléments simples nécessaires à la constitution d'un rechargement sont :
le type de cartouche : décomposable en : un calibre (valeur unique), une marque, une Lg max de cartouche ...
Le type de balle : décomposable en : marque fabricant, Reference (valeur unique)
Le type de poudre : décomposable en : marque de poudre, Reference (valeur unique)
(je passe sur l'amorce, douille etc ... le principe est le même)
Si je choisi parmi les éléments simples précédents, ceux qui m’intéressent pour exécuter un rechargement donné,
je n'ai plus qu'à rajouter les valeurs des poids de poudre, de balle pour obtenir un rechargement valide.

Comme le dit Davep, mon souci n'est plus tellement dans l'organisation de la BDD mais dans l'utilisation de cette foutue base
avec visual studio qui me permet de réaliser les formulaires utilisateurs.
Sous excel, c'est facile, on rempli les petites cases des formulaires et on les écrit dans un ordre pré établi dans le fichier excel.
Là, il faut que j'assimile d'abord le fonctionnement de l'outil visual studio avec une base SQL. (jamais vu aucun des deux .. )
Et puis les SELECT "toto" FROM "La classe à toto" WHILE "tant que j'ai pas fini" ... GRRRRRRRRRRRRRR !

Merci

bubble a écrit:

Gaby53 a écrit:Mais : je suis vraiment nul en BDD; je ne comprends pas comment organiser mes tables dans la base.
[...]
Quels sont les champs à entrer dans cette table ?
Est ce qu'il faut tous les répéter ou je peux faire des liaisons avec les tables "balle", "cartouche" etc..

Merci d'avance.

A mon avis c'est bien une question de modélisation ...

Merci
C'est fait, enfin je crois. (c'était bien aussi un problème de modélisation)
J'ai fait une petite base et j'essaie de jouer avec des formulaires pour lire et écrire des infos dedans;

davep a écrit:Apparement son problème n'est pas au niveau de design de la bdd, mais l'accès aux données depuis un autre logiciel.

Les deux mon général.
je regroupe, vous allez trop vite

Tu peux déjà essayer de faire les requetes SQL dans le logiciel fourni avec SQL Server.

J'y comprend que dalle à ces machins. C'est diabolique.
Mais, l'est têtu le gazier et surtout, il est à la retraite.

Bonjour,
ça y est, j'ai organisé ma base et je crois que c'est "bon".
Mais, car il y a toujours un "MAIS" , je bloque sur l'exécution d'une requete SQL.

Essaie sur 2 tables simples :
- Table1= TFabricant [IdFabricant, Fabricant]
- Table2 = TCartouche[IdCartouche,Calibre,IdFabricant]
Les Colonnes Id... sont des clés uniques à valeurs auto incrémentées.
La colonne IdFabricant de la Table2 pointe sur la colonne de même n° de la table1.
Jusque là, tout va bien.
Je voudrais rajouter une ligne dans la Table1 (TFabricant) par une requete SQL;
En fait, rajouter seulement un Nom de Fabricant.
C'est là que ça coince.
exemple de code :
- Code1 : (qui fonctionne mais je vois mal l'utilisateur d'une base de données taper lui même les requêtes SQL )
pStrRequete = "INSERT INTO TFabricant (Fabricant) VALUES ('titi')"
Execute_Requete()
Là, OK, la fonction rajoute bien le nom "titi" dans la table TFabricant en fin de liste.

- Code2 (problème de syntaxe ??)(ne fonctionne pas)
Dim resu as string = "toto" ' il faut insérer le contenu de res
pStrRequete = "INSERT INTO TFabricant (Fabricant) VALUES (resu)"
Execute_Requete()
=> Impossible de signaler qu'il faut insérer le contenu de la variable resu ???
J'ai essayé plusieurs combinaisons pour écrire resu; 'resu', "'resu'", ou encore &resu& etc ...
recherché sur le net mais là, je sèche.

Si une bonne âme pouvait me renseigner, je lui en serait très reconnaissant.
merci

Ci dessous le code de la procédure Execute_Requete()

Spoiler:

Re,
J'ai fini par trouver ... C'était bien une erreur de syntaxe élémentaire dans la requête.
la réponse :
Dim resu as string = "Albert"
pStrRequete = "INSERT INTO TFabricant (Fabricant) VALUES ('" & resu & "')"
J'avais pas respecté les espaces entre les "&" et la variable.
Je vais , enfin, pouvoir finir mes formulaires.
Merci à ceux qui ont peut être commencé à chercher une solution.

Un peu en retard mais bon...


Le rechargement, ce n'est pas mon domaine, donc les valeurs ci-dessous sont farfelues.
Mais SQL, là je maîtrise nettement mieux !

Voici un petit modèle de données et son jeu de test.
- Toujours mettre des clés primaires uniques (id_xxx) dans une table de référentiel (balles et cartouches). Ca aide énormément ensuite.
- La table recharges possède donc des clés étrangères vers chacune des tables de référentiel.
- Sécurité : pour éviter de mettre une charge de 12.7 dans une 22LR, il faut intégrer des contrôles à la conception.
Ici c'est le calibre qui fait office de garde-fous.
On suppose qu'une balle est forcément adaptée à un seul calibre générique.
On rajoute cette info dans la table balle. C'est un cas où la redondance est justifiée.
Ainsi on interdit les combinaisons balle/cartouche incohérentes par la restriction where calibre dans la vue.
Les colonnes remarques en clair ajoutent aussi de la sécurité. On peut voir directement si la balle et la cartouche sont ok.
Lorsque le programme et surtout les données sont bien au point, on peut ne plus afficher ces colonnes.

Dans le jeu de données ci-dessous :
- La balle speer va avec deux cartouches (12.7).
- La balle Hornady n'a qu'une correspondance.
- La balle PanPan (22lr) n'a pas de cartouche.
- La cartouche pour Kalache n'a pas de balle.
Ca doit se retrouver à l'exécution de la vue.

Pour aller plus loin, il faudrait créer des procédures d'insertion avec contrôle de cohérence (create proc...).


Attention, n'ayant pas de SQL server sous la main, je n'ai pas testé la syntaxe. C'est tout fait de tête. Vérifications d'usage donc.

Code:


/* Tables */
/* ------ */
   create table balles
   (
        id_balle int identity         -- clé primaire
      , marque_bal varchar(30)
      , reference_bal varchar(30)
      , calibre_bal varchar(30)
      -- ...
      , rmq_bal varchar(100)
   ) ;

   create table cartouches
   (
        id_cartouche int identity      -- clé primaire
      , marque_ctch varchar(30)
      , calibre_ctch varchar(30)
      , lg_ctch_CIP decimal(6,3)      -- numérique si calculs
      , lg_douille_CIP decimal(6,3)
      -- ...
      , rmq_ctch varchar(100)
   ) ;

   create table recharges
   (
        id_balle int               -- clé étrangère
      , id_cartouche int            -- clé étrangère
      , masse_poudre_grammes decimal(6,3)   -- numérique si calculs
      , lg_douille_recoupee varchar(30)
      -- ...
      , rmq_charge varchar(100)
   ) ;
   go
   
/* Vue d'affichages des correspondances de chargement */
/* -------------------------------------------------- */
   create view voir_recharges
   as
   select
        marque_bal, reference_bal, calibre_bal
      , marque_ctch, calibre_ctch, lg_ctch_CIP, lg_douille_CIP
      , masse_poudre_grammes, lg_douille_recoupee
      , rmq_bal, rmq_ctch, rmq_charge
   from recharges r
   join balles b on b.id_balle = r.id_balle
   join cartouches c on c.id_cartouche = r.id_cartouche
   where c.calibre_ctch = b.calibre_bal ;
   go
   
/* Remplissage */
/* ----------- */
   -- insertion de 3 balles
   insert into balles (marque_bal, reference_bal, calibre_bal, rmq_bal)   -- id = 1, par identity.
   values ('Hornady', 'ref0001', '357M', 'Balle en plomb wadcutter 357 magnum extra') ;

   insert into balles (marque_bal, reference_bal, calibre_bal, rmq_bal) -- id = 2
   values ('Speer', 'num 35468', '.50', 'Balle 12.7 spéciale terroriss') ;
   
   insert into balles (marque_bal, reference_bal, calibre_bal, rmq_bal) -- id = 3
   values ('PanPan', '125-s', '22lr', 'Balle 22lr bosquette') ;

   -- insertion de 3 cartouches
   
   insert into cartouches (marque_ctch, calibre_ctch, lg_ctch_CIP, lg_douille_CIP, rmq_ctch) -- id = 1
   values ('Remington', 'ABC_666', '.50', 99, 75, 'Cartouche Desert Eagle .50') ;
   
   insert into cartouches (marque_ctch, calibre_ctch, lg_ctch_CIP, lg_douille_CIP, rmq_ctch) -- id = 2
   values ('Winchester', 'abc', '.50', 99, 75, 'Cartouche Smith&Wesson 12.7') ;

   insert into cartouches (marque_ctch, calibre_ctch, lg_ctch_CIP, lg_douille_CIP, rmq_ctch) -- id = 3
   values ('Winchester', 'zyw', '7.62', 56, 39, 'Cartouche pour Kalache') ;
   
   insert into cartouches (marque_ctch, calibre_ctch, lg_ctch_CIP, lg_douille_CIP, rmq_ctch) -- id = 4
   values ('Remington', 'FTR_081', '357M', 40, 33, 'Cartouche pour 357 magnum') ;

   
   -- Insertion des correspondances de chargement
   insert into recharges (id_balle, id_cartouche, masse_poudre_grammes, lg_douille_recoupee, rmq_charge)
   values (1, 4, 8.1, 33, 'Charge Hornady ref0001 pour Remington FTR_081 (357M)' ;
   
   insert into recharges (id_balle, id_cartouche, masse_poudre_grammes, lg_douille_recoupee, rmq_charge)
   values (2, 1, 20, 75, 'Charge speer num 35468 pour Remington ABC_666 (DE 12.7)' ;
   
   insert into recharges (id_balle, id_cartouche, masse_poudre_grammes, lg_douille_recoupee, rmq_charge)
   values (2, 1, 20, 75, 'Charge speer num 35468 pour Winchester abc (SW12.7)' ;

   go

/* Visualisation */
/* ------------- */
   
   select * from voir_recharges ;



Bonjour,
Il n'est jamais trop tard.

Effectivement je patauge toujours sur l'organisation de la base.
Mais comme, en même temps, j'essaie d'apprendre l'usage de visual basic express 2010 avec les Bdd ... j'ai du boulot.
( pas simples les notions de dataset, datatable ... avec visual et surtout sur les requêtes sql à fabriquer selon ce que je veux inscrire dans les grilles d'affichage ou les contrôles de saisie)
Je viens de faire un premier schéma de base :

Spoiler:

Je sais pas s'il est juste car c'est pas très clair dans ma tête.(y a rien de clair d'ailleurs )
Globalement :
- chaque table a une clé primaire.
- la table TRechargement rassemble tous les rechargements de cartouches "validés" :
[pour un calibre, une balle et son poids, poudre et son poids etc..)]
Les autres sont les éléments constitutifs servant au rechargement d'une cartouche.
Chaque élément est caractérisé (en général) par une référence (ou désignation), un fabricant et d'autres données particulières)
comme chaque élément provient d'un fabricant, j'ai mis une table TFabricant à part.
Dans ce domaine on retrouve souvent les mêmes noms pour des éléments de munitions. (sauf la poudre peut être)

Voilà, j'essaie de commencer avec ce schéma; après je rajouterai une table "TSuiviRechargement" qui regroupera les "expériences de création de nouveau rechargement ou de fabrication de lots de munitions à partir des données d'un rechargement valide.

un grand merci pour ces infos; je vais décortiquer ça dès mon retour.