Bonjour à tous !

Je gère une base de données Access relatives aux appareils photos (Reflex, smartphones…) et à leurs données techniques (longueur focale, taille d’image, ouverture, etc.).

Cette base de données est intégrée et exploitée dans un gros logiciel de traitement d’images.

Pour des raisons de lourdeur et de problèmes d’installation d’Access/Office (merci Microsoft…) et sur conseils je souhaite migrer ma base en SQL.

N’y connaissant strictement rien, j’ai scrupuleusement suivi les cours sur l’administration des bases de données avec MySQL délivrés ici même, et qui sont vraiment super bien faits.

J’ai pu ainsi, d’abord en ligne de commande, puis avec l’interface graphique HeidiSQL, construire la structure de ma BD, puis exporter et importer toutes mes données (avec du .csv) dans cette nouvelle BD MySQL sans aucun problème.

Pour des besoins liés au mode de fonctionnement du logiciel utilisant cette BD et pour des raisons pratiques, certaines données de ma table-maître (appelée « base ») relatives à certaines données techniques des appareils photos s’étalent sur deux colonnes, l’une avec une valeur « min » possible, l’autre avec une valeur « max » possible, ce qui est gérable en aval par le logiciel. C’est le cas pratiquement par exemple pour les données relatives à l’ISO, la longueur focale, l’ouverture ou encore le temps d’exposition. Ici, aucun problème avec MySQL.

CREATE TABLE `base` (
	`id` MEDIUMINT(8) UNSIGNED NOT NULL AUTO_INCREMENT,
	`FOV (deg) min` DECIMAL(3,2) UNSIGNED NULL DEFAULT NULL,
	`FOV (deg) max` DECIMAL(5,2) UNSIGNED NULL DEFAULT NULL,
	`Make` VARCHAR(50) NOT NULL,
	`Model Name` VARCHAR(200) NOT NULL,
	`Sensor height (mm)` DECIMAL(4,2) UNSIGNED NULL DEFAULT NULL,
	`Sensor width (mm)` DECIMAL(4,2) UNSIGNED NULL DEFAULT NULL,
	`Type` CHAR(5) NOT NULL,
	`Version` DECIMAL(3,2) UNSIGNED NOT NULL,
	`Lens Mode` VARCHAR(10) NOT NULL,
	`Lens Configuration` CHAR(1) NOT NULL,
	`Support` CHAR(1) NOT NULL,
	`Image Size` VARCHAR(200) NULL DEFAULT NULL,
	`Format` VARCHAR(4) NULL DEFAULT NULL,
	`Band` VARCHAR(6) NOT NULL,
	`Interchangeable Lens` CHAR(1) NOT NULL,
	`Circle Of Confusion` VARCHAR(4) NULL DEFAULT NULL,
	`YCbCr subsampling` CHAR(3) NULL DEFAULT NULL,
	`ISO min` MEDIUMINT(8) UNSIGNED NULL DEFAULT NULL,
	`ISO max` MEDIUMINT(8) UNSIGNED NULL DEFAULT NULL,
	`Flash range (m)` DECIMAL(4,2) UNSIGNED NULL DEFAULT NULL,
	`Burst rate (Hz)` DECIMAL(3,2) UNSIGNED NULL DEFAULT NULL,
	`Exposure Time (s) max` DECIMAL(8,4) UNSIGNED NULL DEFAULT NULL,
	`Exposure Time (s) min` DECIMAL(9,8) UNSIGNED NULL DEFAULT NULL,
	`F Number min` DECIMAL(3,1) UNSIGNED NULL DEFAULT NULL,
	`F Number max` DECIMAL(4,1) UNSIGNED NULL DEFAULT NULL,
	`Focal Length (mm) min` DECIMAL(4,2) UNSIGNED NULL DEFAULT NULL,
	`Focal Length (mm) max` DECIMAL(6,2) UNSIGNED NULL DEFAULT NULL,
	`Equivalent focal length 35 mm camera (mm) min` DECIMAL(4,1) UNSIGNED NULL DEFAULT NULL,
	`Equivalent focal length 35 mm camera (mm) max` DECIMAL(5,1) UNSIGNED NULL DEFAULT NULL,
	`Video Frame Rate` SMALLINT(5) UNSIGNED NULL DEFAULT NULL,
	PRIMARY KEY (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
AUTO_INCREMENT=4
;

D’autres données en revanche ne peuvent être renseignées de la sorte, car de multiples choix possibles et différents (trop !) existent. C’est le cas des données relatives par exemple aux tailles possibles d’images ou au nom de la caméra (il existe en effet parfois de nombreux alias pour certains modèles).

Dans Access, j’avais créé, en parallèle de ma table-maître, des tables comportant toutes les valeurs possibles relatives à ces données (ce ne sont en fait que de bêtes listes !) ainsi que les relations les liant à la table maître. Je pouvais ainsi, pour chaque appareil sélectionner dans la colonne concernée de ma table-maître autant de données que nécessaire issues d’une autre table, le résultat s’affichant en clair dans un champ avec le séparateur point-virgule, le tout étant là aussi très bien géré en aval par le logiciel.

Dans une BD relationnelle SQL, je sais qu’on ne doit pas stocker plusieurs valeurs dans un même champ, mais du coup je me demandais quelle serait la meilleure solution pour obtenir le même résultat, ou du moins le plus proche qu’avec Access, soit attribuer à un appareil donné dans une colonne donnée soit rien, soit une valeur soit plusieurs.

Mais peut-être que j'ai mal ficelé dès le départ ma table-maître!

Merci d’avance pour votre aide.

Bonjour,

AntoineCousyn a écrit:

attribuer à un appareil donné dans une colonne donnée soit rien, soit une valeur soit plusieurs

Si l'on prend l'exemple de la donnée "Format". Un appareil pouvant proposer plusieurs formats et un format pouvant être proposé par plusieurs appareils .

Cela s'appelle une relation n,n. Il faut que tu disposes donc d'une table de relation. Le modèle serait en trois tables :

• appareil ( id [pk], etc. )
• format ( id [pk], libelle )
• appareil_format ( id_appareil [pk][fk], id_format [pk][fk] )

Pour chaque donnée impliquant une relation n,n il te faudra une structure de ce genre ...

Par ailleurs je t'encourage à renommer tes noms de colonnes de manières plus normalisée, sans accents, sans espaces, sans caractères spéciaux.

Ceci pour te faciliter l'écriture des requêtes et t'éviter de potentiels problèmes d'encodage ...

Merci pour ta réponse.

Avant de suivre tes instructions pour la création de ma première table de relation, je voudrais être bien sûr que j'utilise la bonne syntaxe pour les noms que j'emploie aussi bien pour mes tables que pour mes colonnes.

Je n'ai pas d'accents ni de caractères spéciaux dans ces noms, en revanche j'ai effectivement des espaces. Est-ce possible de les conserver en les remplaçant par un underscore ou dois-je absolument ne pas laisser d'espace?

Autre détail, j'ai parfois nommé une colonne de la même manière que la table la contenant avec juste une majuscule au lieu d'une minuscule, par exemple la table format contient les deux colonnes id et Format. Est-ce acceptable ou est-il préférable de renommer ma colonne en quelquechose de plus générique comme "nom" (ou "name")?

Je vais tâcher, avec ton aide et celle des cours, de créer ma première table de relation. Cela ne doit pas être bien compliqué, le tout étant je pense de bien comprendre le principe!

AntoineCousyn a écrit:

Je n'ai pas d'accents ni de caractères spéciaux dans ces noms

Attention, pas d'accents ok (vu que tes noms sont en anglais), mais les parenthèses sont des caractères spéciaux, qui plus est utilisés par SQL.

AntoineCousyn a écrit:

j'ai effectivement des espaces. Est-ce possible de les conserver en les remplaçant par un underscore

Oui, c'est ce que je fais de mon côté, et souvent ce qui est conseillé par ailleurs. 

AntoineCousyn a écrit:

la table format contient les deux colonnes id et Format

Je te donne mon avis : dans ton exemple, format est une entité (table), ayant deux attributs (colonne) : un identifiant (ou id) et un libellé (ou nom ou intitulé).

J'écris donc en SQL, format.libelle, c'est compréhensible et non équivoque, personnellement je trouve qu'écrire format.format est faux ... on ne cherche pas le format du format, mais le libellé (ou le nom, ou l'intitulé) du format ... Si vraiment nécessaire, lors de la rédaction des requêtes, tu peux utiliser des alias pour "modifier" le nom retourné par SQL à ton programme qui gère l'affichage ...

AntoineCousyn a écrit:

créer ma première table de relation. Cela ne doit pas être bien compliqué, le tout étant je pense de bien comprendre le principe!

Oui. Avant tout, essaye de bien assimiler les notions de clé primaire et de clé étrangère.

https://openclassrooms.com/fr/courses/1959476-administrez-vos-bases-de-donnees-avec-mysql/1963057-cles-primaires-et-etrangeres

Dans tous les cas, la lecture complète du cours MySQL (au moins les 4 premières parties) te sera vraiment utile pour t'éviter les écueils communs

-
Edité par Benzouye 16 juillet 2019 à 11:34:13