Discussion :

[JediMaster]

Bonjour,
J'ai actuellement un problème de conception au niveau de ma base de donnée.
J'ai une application qui vends plusieurs type de produits.
J'aimerais que tout les produits soir dans une table produits (pour un id commun a tous les produit).
Je dois vendre des ordinateurs qui auront une marque et un modèle comme information
Je dois aussi vendre des livres qui auront une photo, un titre et un auteur.

PS: même si ce n'est pas très réaliste c'est un exercice. Mon problème vient du fait que les description seront stockées dans des tables différentes selon le produit. J'aimerais faire quelque chose de correct (normalisé).

voila un petit dessin de mon problème (justement je ne veux pas ça)

[CinePhil]

voila un petit dessin de mon problème (justement je ne veux pas ça)

Pourquoi tu ne veux pas ça ?
C'est de l'héritage et c'est bien comme ça qu'il faut faire pour des familles de produits différents qui n'ont pas la même description.

Si le nombre de familles de produits augmente de façon significative, il est possible d'envisager une autre stratégie qui consiste à avoir une entité Caractéristique liée à l'entité Produit (ci dessous un extrait de MCD Merise) :
Produit -0,n----Avoir----0,n- Caractéristique

Dans Caractéristique, on trouverait les attributs (C_id, C_Libelle) et dans l'association Avoir l'attribut Valeur.
Ainsi, plusieurs produits peuvent avoir des caractéristiques en commun mais pas forcément avec la même valeur.
Seul inconvénient de cette méthode : le type de l'attribut Valeur sera VARCHAR et s'il y a beaucoup de produits avec des valeurs numériques sur lesquelles peuvent être faites des calculs, le SGBD doit convertir le VARCHAR en numérique et ça peut ralentir l'exécution des requêtes.

[JediMaster]

Au niveau des classes je fais effectivement de l'héritage mais pour ma base de données j'ai l'impression que ça conception n'est pas bonne du fait de la cardinalitée descriptionLivre 0..1 Produit 0..1 descriptionOrdinateur ( Je ne me rappelle plus vraiment des normalisations de bd)

Cependant si tu me dit que c'est bon alors j'opte pour cette solution, j'avais un doute mais je ne trouvais pas d'autre solution.
C'est un petit projet donc je n'ai pas besoin d'utilisé ton second exemple qui n'en n'ait pas moins intéressant ( je le note pour plus tard )

Merci beaucoup en tout cas, je peux foncer donc.

[JPhi33]

Bonjour JediMaster,

J'aimerais que tout les produits soir dans une table produits (pour un id commun a tous les produit).

Il n'est pas nécessaire que les produits soient dans la même table pour pouvoir les identifier par un id commun.

Pour comprendre cela, il faut revenir au niveau conceptuel ; niveau à partir duquel il aurait été préférable de débuter le processus de conception de la base de données, soit dit en passant.

Tout d'abord il faut accepter le fait qu'on ne mélange pas, conceptuellement parlant, des voitures et des motos, même si les deux sont des véhicules...

Je dois vendre des ordinateurs qui auront une marque et un modèle comme information
Je dois aussi vendre des livres qui auront une photo, un titre et un auteur.

Et bien, on ne mélange pas des ordinateurs et des livres même si les deux sont des produits. Partant de ce constat, on peut énoncer quelques vérités somme toute très banales :

• en tant qu'ordinateur, un produit a une marque et un modèle, ce que n'a pas un livre
• en tant que livre, un produit a une photo, un titre et un auteur, ce que n'a pas un ordinateur
• en tant que produit, un ordinateur et un livre ont tous les deux un prix et un stock

Autrement dit, les produits partagent des caractéristiques communes (prix, stock) mais chaque type de produit a aussi ses spécificités.
On peut donc dire que l'on un ensemble général des produits et deux sous-ensembles spécialisés inclus dans l'ensemble des produits : l'un pour les produits de type ordinateur, l'autre pour les produits de type livre.
Nous venons de décrire le concept de généralisation-spécialisation qui permettra, dans le modèle logique, d'introduire le mécanisme d'héritage.

Au niveau conceptuel (MCD), ce principe se modélise comme ci-dessous (cliquer pour agrandir).

On notera plusieurs particularités sur ce schéma :

1. Produit est l'entité généralisée
2. Ordinateur et Livre sont les entités spécialisées
3. Ordinateur et Livre n'ont pas d'identifiant
4. le "x" dans le demi-cercle signifie qu'il y a exclusion entre Ordinateur et Livre : un ordinateur n'est pas un livre et réciproquement

Au niveau logique (MLD) Ordinateur et Livre héritent des propriétés de Produit : soit id_produit, prix et stock, soit seulement id_produit. C'est cette dernière option qui est généralement retenue afin d'éviter les redondances de données.

Quand on crée un livre, ses données sont alors réparties dans les deux tables Produit et Livre car un livre est un produit. Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Produit
-------
id_produit   517
prix         39
stock        8


Livre
-----
id_produit   517
photo        <url photo>
Titre        Merise - tome I

Pour reconstituer entièrement les données du livre, il faut faire une jointure de Produit et Livre sur id_produit identique et de valeur 517. En faisant une jointure de Produit et Ordinateur avec id_produit = 517, on n'obtient rien, ce qui est normal puisque le produit 517 est un livre.


Pour en revenir à la question de départ, cette solution est normalisée. Et celle proposée dans le message s'en approche beaucoup.

[CinePhil]

Au niveau des classes je fais effectivement de l'héritage mais pour ma base de données j'ai l'impression que ça conception n'est pas bonne du fait de la cardinalitée descriptionLivre 0..1 Produit 0..1 descriptionOrdinateur ( Je ne me rappelle plus vraiment des normalisations de bd)

Effectivement, j'ai découvert plus tard que ton schéma était en fait un daigramme de classes.
Et dans un digramme de classes, les multiplicités (et non pas les cardinalités de Merise) sont inversées par rapport au cardinalités du MCD Merisien.

MCD :
Ordinateur -(1,1)----Etre----0,1- Produit
Livre -(1,1)------------Etre----0,1-----|

Et comme l'a très bien représenté JPhi33, il faut une croix d'exclusion entre les deux relations.

Diagramme de classes (DC) :
Ordinateur -1------------------0..1- Produit
Livre -1--------------------------0..1-----|

Ton DC est donc bon.

[JediMaster]

Merci pour ces réponses très complète je n'en n'attendais pas autant en tout cas c'est parfaitement expliqué ducoup j'ai tout compris. En fait j'ai jamais utilisé de méthodes Merise et ma conception ce limite à l'UML et les MCD MVC sans justement avoir fait de cour Merise. Donc j'ai tendance a tout représenté en UML même si je sais que c'est pas la solution pour la base de données le rese ce fait dans ma tête. Je me rappelle de 3 normalisations d'une base de donnée mais c'est un peu floue maintenant, vus que tu me confirme que mon diagramme de classe est bon et que ma base de donnée suis alors c'est parfait. Sachant que j'ai fini le tout aujourd'hui je révise un peux les windows form histoire de faire quelque chose de joli. Au passage j'utilise Linq pour ma BD.