Bonjour à tous,

Après avoir rechercher sur la notion d'héritage dans le forum je n'ai rien trouvé à ma question je pense très basique mais je n'ai rien trouvé si ce n'est une littérature un peu obscure pour moi...

Ma question est très simple, j'ai une hiérarchie de classe en java que j'ai simplifié comme cela.

Je me demande comment rentrer cela en base de données.

Alors j'ai bien vu que je pouvais créer donc trois tables afin de factoriser les informations. Mais je me demande si c'est vraiment efficace ? Car à chaque fois que j'aurai besoin des données d'un article je devrais faire une jointure. Est-ce la bonne façon de faire ?

Donc tout simplement faire trois tables afin de factoriser les informations ou pas besoin ? 

Bonjour,

A partir du moment où tu as une classe mère avec des attributs propres et des classes héritées avec leur propres attributs, complétant ceux de la classe mère, l'héritage est une solution "normalisée". Cela t'évites d'avoir 2 tables avec des attributs redondants ...

Cela oblige en effet à faire une jointure vers la table fille à chaque fois, mais c'est ainsi ...

Toutefois dans un contexte de "boutique" comme ce semble être le cas ici, on va souvent favoriser un modèle dénormalisé de type "métadonnées".

Une table "produit" avec tous les attributs communs, une table caractéristique (id, nom) listant les attributs possibles ( couleur, grip, pointure, etc. ) et une table de relation produit_caracteristique ( id_produit, id_caracteritique, valeur ) pour associer un produit à ses caractéristiques avec la valeur de chacune. C'est moins propre, mais beaucoup plus simple à utiliser et à faire évoluer.

Au passage, dans ton modèle l'attribut couleurDominante de la classe raquette est inutile puisqu'il appartient aussi à la classe mère ...

Bonjour "Benzouye",

Merci de ta réponse très claire et très complète.

Du coup à la fin on se retrouve avec 3 tables. Une avec les propriétés "factorisées" et l'autre avec toute la liste possible et enfin une table de "liaison". Pourquoi avoir une table qui fait "la liaison" ?

Du coup pour savoir ce qu'est le type d'un produit il faudra faire une propriété "typeProd" et là pour être sur d'avoir une bonne valeur dedans on définit une énumération ? (mais là on sort de la question principale).

Merci encore !

Elu340 a écrit:

Pourquoi avoir une table qui fait "la liaison" ?

Car tu as une relation de plusieurs à plusieurs (many to many). Un produit a plusieurs caractéristiques, et une caractéristiques peut être liées à plusieurs produits. Sans table de relation, tu ne peux pas stocker cela proprement dans une base de données relationnelle ...

Je te conseille la lecture du doc "Conception BDD" (cf. ma signature).

Elu340 a écrit:

une propriété "typeProd" et là pour être sur d'avoir une bonne valeur dedans on définit une énumération ?

Pour cela, on peut améliorer le modèle en créant une table pour stocker les valeurs possibles d'une caractéristiques. Ce qui ferai :

• produit ( id_produit [pk], designation, etc. )
• caracteristique ( id_caracteristique [pk], libelle )
• valeur ( id_valeur [pk], id_caracteristique [fk], libelle )
• produit_caracteristique ( id_produit [pk][fk], id_caracteristique [pk][fk], valeur, id_valeur [fk] )

Merci encore pour cette belle réponse complète.

J'ai vraiment du mal, j'avais appris à l'université les "lois de Codd", oncle Ted et le peu que j'en ai pratiqué en projet de fin d'années (je parle des bases de données) on enlevé justement tout les formes normales... Finalement j'ai du mal à comprendre les "règles" qui doivent s'appliquer sur une base de données...
Pour moi c'est un peu comme si on mettait les attributs d'un objet en public pour eviter de faire des setters et dire "oui bah on code plus vite comme ça ! ".

Je me demande du coup à quoi serve les énumérations... Pardon j'ai peut être appris les choses un peu trop de manière "scolaire" et sans esprit critique... Ce qu'aujourd'hui j'essai d'améliorer...

Au fait j'entends par "typeProd" c'est à dire si l'élement est une : " raquette de tennis, paire de chaussure, balle, filet...". Après comme ce serait moi qui ferait le script des INSERT j'ai envie de dire je ferai attention. Ou alors je peux créer un Trigger à l'INSERT qui vérifie le bon type de tout ça, ou alors juste l'énumération... J'ai l'impression que en BD on peut faire beaucoup plus "n'importe quoi" alors qu'en POO etc on a mit des guidelines, framework, template en place... 

Pardon de mon inexpérience qui peut surgir de mon commentaire...

Elu340 a écrit:

Je me demande du coup à quoi serve les énumérations

Les ENUM vont servir lorsque tu es sûr que la liste des valeurs possibles pour une colonne est connue d'avance et figée dans le temps. Par exemple pour stocker le sexe d'une personne (Masculin ou Féminin ... bon je sais que c'est parfois plus compliqué, mais admettons), tu peux utiliser un ENUM( M, F ).

Dans ton cas, les caractéristiques vont sûrement évoluer (ajout, suppression, modification), il est donc plus maintenable et évolutif d'utiliser une table de référence pour éviter d'avoir à modifier la structure de la base à chaque fois qu'une caractéristique doit être ajoutée, modifiée ou supprimée ...

Elu340 a écrit:

j'ai du mal à comprendre les "règles" qui doivent s'appliquer sur une base de données

Je te propose de lire le doc "Conception BDD" cf. ma signature. C'est complet et assez accessible au profane.

Elu340 a écrit:

j'entends par "typeProd" c'est à dire si l'élement est une : " raquette de tennis, paire de chaussure, balle, filet..."

Je n'avais pas capté Si tu n'utilises pas l'héritage, alors il faudra en effet que sur la table produit il y ait une colonne permettant de distinguer le type de produit. Et si l'on reprend le premier point, je te conseille de faire une table de référence (type_produit) avec une clé étrangère dans la table produit ...

Elu340 a écrit:

J'ai l'impression que en BD on peut faire beaucoup plus "n'importe quoi" alors qu'en POO etc on a mit des guidelines, framework, template en place...

Une base de données n'est pas une application ... Elle sert "juste" à stocker les données et à en assurer l'intégrité. Par contre c'est à toi de mettre en place les mécanismes de gestion d'intégrité (clé primaire, clé étrangère, index, trigger, etc.) pour respecter les règles de gestion souhaitées.

Dans ton cas, on faudrait par exemple mettre en place une table de relation entre type_produit et caracteristique pour décrire quelle caractéristique va avec quel type de produit, et au moment de l'insertion de couple produit/caractéristique utiliser un TRIGGER pour s'assurer que l'on lie un produit avec une caractéristique adaptée à son type ...

Au final le modèle devient :

• type_produit ( id_type [pk], libelle ) avec UNIQUE( libelle )
• caracteristique ( id_caracteristique [pk], libelle ) avec UNIQUE( libelle )
• type_caracteristique ( id_type [pk][fk], id_caracteristique [pk][fk] )
• produit ( id_produit [pk], id_type [fk], designation, etc. )
• valeur ( id_valeur [pk], id_caracteristique [fk], libelle ) avec UNIQUE( id_caracteristique, libelle )
• produit_caracteristique ( id_produit [pk][fk], id_caracteristique [pk][fk], valeur, id_valeur [fk] )

Avec ce modèle, il faut mettre en place un TRIGGER BEFORE INSERT ON produit_caracteristique qui va vérifier que la caractéristique est bien liée au type de produit concerné, et que l'id_valeur est bien lié à la caractéristique concernée.

Bonsoir Benzouye,

Encore merci pour ton aide, je n'ai pas eu le temps de continuer à travailler le projet car j'ai eu des imprévus (le monde de l'informatique !). Mais j'ai bien pris note du pdf et j'ai commencé à le lire. Pour ne pas "poluer" le forum et détérrer ce sujet qui va vieillir pourrais-je vous envoyer un lien privé pour continuer la discussion une fois que j'aurai du temps libre devant moi ou bien continuer sur ce post ?

Merci encore pour l'aide,

Sam'

Bonjour Benzouye,

Alors je reviens vers vous après avoir lu ce fantastique cours. Les exemples sont très pertinent, j'espère en avoir bien compris les principes !
Donc si vous voulez bien m'accompagner dans ma démarche d'élaboration de base de données. Effectivement je souhaite faire une petite application de e-commerce.

En partant du schéma conceptuel (entité/association) voilà ce que je détecte :

• Client(identifiant, motdepasse, email)
• Adresse(nom,prenom,civilite,numrue,nomrue,codepostal)
• Articles(identifiant, [toutes les caractéristiques],prixachat,prixvente,stock,typearticle]
• Facture(identifiant,identifiant_client,datefacture)
• Lignefacture(identifiant, identifiant_article,identifiant_produit quantite);

Pour l'instant c'est le "plus simple" c'est le niveau conceptuel, voyez vous de grosses fautes ou des choses à corriger ? Je crois suivre les 3 premières règles de normalisation.

J'ai fais un MCD : 

-
Edité par Elu340 14 décembre 2019 à 17:50:42

Tu devrais utiliser un logiciel de modélisation, ce serait plus pratique ...

Là tu as mélangé mcd et mld...

La facture est une entité à part, ce n'est pas une relation.

Il te faut bien formaliser tes cardinalités pour bien représenter ton modèle conceptuel dont découle ton modèle logique. 

Encore un effort, n'hésites pas à regarder des exemples de MCD ...

Bonsoir Benzouye,

Encore merci de tes réponses. Je pense que ce MCD est correct pour le coup : 

-
Edité par Elu340 31 décembre 2019 à 19:29:20

Non...

La commande est liée à un client avec une relation 1,n (1 client passe n commandes), pas à l'article ...

Num client ne doit pas apparaître dans l'entité adresse tant que tu es dans ton MCD...

Voilà j'ai inversé les deux entités, c'est vrai c'est plus logique. 

Je ne vais pas abuser plus de ton aide, je pense qu'avec ce que j'ai lu mon petit projet étudiant est correct et au pire je relirai mais je ne me sens pas bloqué avec cette construction pour un "exercice one shoot". Sauf grosse erreur je pense que l'on pourra archiver

J'ai conscience que j'ai beaucoup simplifié la gestion des articles, je ferai du PL/SQL pour contrôler l'ajout correct de produits etc. 

Encore merci beaucoup ?

-
Edité par Elu340 1 janvier 2020 à 23:15:59