Discussion :

[BastGui]

Bonsoir,

Je viens demander de l'aide désespérément, je ne sais pas du tout si je suis au bon endroit. Alors voilà, j'ai un projet d'informatique pour ma L2 à rendre en décembre 2016. Je dois créer un site de recette culinaire, et je ne m'y connais absolument pas en informatique (programmation, base de données etc)
Pour bien débuter j'aimerai avoir un diagramme entité/association correct.
Merci beaucoup d'avance si vous pouvez faire quelque chose pour moi!!! Vous allez me sauver la vie!!!
Bonne soirée!!


Voici mon projet :

1 Des spécifications au script SQL

Ce jeu de données porte sur des recettes de cuisine, composées de produits et ingrédients, et proposées par
des utilisatrices. Tout d’abord, les recettes ont un titre, une catégorie (e.g., ”plat”, ”dessert”) et une description
optionnelle. Une recette est élaborée pour un nombre de personnes. Chaque recette se découpe en étapes, qui
sont numérotées. Chaque recette a au moins une première étape. Une étape comporte des instructions à suivre.
Enfin, chaque étape nécessite un certain nombre d’ustensiles de cuisine, dont on stocke uniquement le nom. En
effet, on considère que la personne qui cuisine connait le rôle de chaque ustensile. Chaque recette est proposée
par une utilisatrice à une date donnée. Une utilisatrice se caractérise par un nom, un prénom, une date de
naissance, un genre (femme/homme), un email (unique), une date d’inscription. Une utilisatrice possède également
une adresse. Le dernier concept est celui de lieu, représenté simplement par une latitude et une longitude.
Mais il y a deux types de lieux : les zones géographiques, pour lesquelles on connait un continent et/ou un
pays, et les adresses, qui sont décrites par un pays, une ville, un code postal, et une adresse (voie et numéro
de voie). Il reste à décrire les produits et les ingrédients, qui sont utilisés par les recettes. Un ingrédient est
une matière première (e.g., une tomate, un oeuf) tandis qu’un produit est transformé à partir d’au moins deux
ingrédients (e.g., une pâte brisée). Un ingrédient possède un nom, une catégorie (e.g., légume, épice) et un lieu
et date de provenance. Il n’est pas rare qu’un ingrédient provienne de différents lieux (e.g., des kiwis de France
ou de Nouvelle-Zélande). Un produit est décrit par un nom, une catégorie, une date de fabrication, un lieu de
fabrication unique, et la quantité de chaque ingrédient qui a servi à sa fabrication. Pour chaque ingrédient et
pour chaque produit, on stocke dans la base la quantité disponible (indépendamment d’une unité). Enfin, une
recette se compose de produits et/ou ingrédients dans une certaine quantité. Les quantités utilisées pour les
recettes sont exprimées dans une unité donnée (e.g., gramme, litre, pièce) ou l’abréviation correspondante (e.g.,
gr, L).
1. Produisez un diagramme entité / association pour ces spécifications.
2. Produisez le schéma relationnel dérivé de votre diagramme E/A. Si vous générez ce schéma avec un outil
de modélisation, il est recommandé de le vérifier et éventuellement de le corriger / compléter.
3. Produisez le script SQL permettant la création de la base de données. Si vous générez ce script avec
un outil de modélisation, il sera nécessaire de le vérifier et de le corriger / compléter (ces modifications
devraient être stockées dans un autre fichier que celui généré par l’outil de modélisation)


J'ai oublié de poster mon schéma :

[escartefigue]

Bonjour,

Je vois que vous avez ajouté votre MCD

Deux remarques d'ordre général :
- n'utilisez jamais d'identifiant fonctionnel en tant qu'identifiant primaire : un identifiant primaire doit être stable et concis.
Stable: l'identifiant est propagé dans l'ensemble des tables qui sont en relation avec la table où il est identifiant primaire, et au delà si on utilise l'identification relative. Du coup, en cas de mise à jour, ce sont de nombreuses lignes qui sont impactées, ce qui pénalise les perfs (et peut même mettre à plat la base de données en cas de MàJ en masse)
Concis : l'identifiant primaire est celui qui est utilisé par le SGBD pour vérifier l'intégrité des données, et c'est le plus utilisé dans les jointures. Plus il est long, plus ça sollicite la CPU et le moteur de la base de données, là encore au détriment des perfs.
C'est la raison pour laquelle il est fortement recommandé d'utiliser un identifiant primaire technique, attribué par le SGBD, et de format integer
Bien sur, vous créerez aussi dans votre base de données des identifiants secondaires fonctionnels pour permettre la recherche par nom, par code ou tout autre critère

- L'usage est d'utiliser des verbes pour les associations, ca permet de lire l'association dans les 2 sens
Exemple: RECETTE 1,n --- inclure --- 1,n ETAPE (la recette inclut des étapes, et l'étape est incluse dans une ou plusieurs recettes)

Concernant votre proposition de modèle :
Il faut tout d'abord avouer que l'énoncé comporte quelques curiosités, à commencer par la gestion des lieux
En quoi la provenance géographique d'un ingrédient ou d'un produit présente un intérêt pour une recette et encore plus la latitude et la longitude...

Utilisateurs :
Vous avez choisi l'option selon laquelle un utilisateur n'est connu qu'à partir du moment où il a proposé au moins une recette (cardinalité mini 1). Ce n'est pas précisé dans l'énoncé, mais ca semble cohérent. Pensez (cf. remarque d'ordre général) à ajouter un identifiant technique comme id primaire (ex id_util integer identity)

Recette :
Il manque le nombre de personnes, et la catégorie doit être la conséquence d'une relation : RECETTE 1,1 --- catégoriser --- 0,n CATEGORIE

Se décompose :
Je pense qu'une étape peut servir à plusieurs recettes, par exemple "éplucher les pommes de terres" (qui nécessite un économe) sera utilisée pour le gratin dauphinois et le hachis parmentier

Etape :
Il peut y avoir plusieurs instructions par étape, il faut donc là aussi sortir l'instruction de l'étape : ETAPE 1,n --- inclure --- (1,1) INSTRUCTION
Notez les parenthèses que j'ai mises sur les cardinalités coté INSTRUCTION. C'est ce qui matérialise l'identification relative
Si besoin d'infos sur l'identification relative, vous pouvez lire la réponse n°12 de ce sujet : http://www.developpez.net/forums/d16...g/#post8789962

Nécessite :
Toute étape ne nécessite probablement pas d'ustensile, par exemple l'étape "laver les légumes" ne nécessite qu'un évier (qui n'est sans doute pas considéré comme un ustensile)

Je reviendrai vers vous pour la partie ingrédients et produits

[escartefigue]

Concernant la partie gauche de votre MCD :
Provient_de :
D'après l'énoncé, la provenance n'est pas une association qui concerne les recettes mais les produits et les ingrédients

Se_compose_de_produits :
La quantité doit aussi apparaitre ici. En effet le même produit apparaitra en quantité différente selon la recette.
Ajoutez aussi l'unité de mesure de la quantité

Quantite_necessaire :
Que voulez vous matérialiser par cette association ?

Produit :
Vu avec Se_compose_de_produits, il faut supprimer la quantité ici
Le lieu doit être la conséquence d'une relation entre PRODUIT et LIEU, il faut donc supprimer l'attribut lieu (même si c'est un lieu unique)
La quantité qui apparait ici est la quantité totale disponible (et non celle requise pour une recette, cf. plus haut). il manque l'unité de mesure
Note : il convient de mettre les noms des entités-type au singulier (une entité-type contient plusieurs occurrences d'entités), Produit donc plutôt que Produits

Se_compose_d'ingrédients :
Je ne suis pas sur qu'une recette puisse ne comporter aucun ingrédient ? auquel cas la card mini coté recette devient 1
Même remarque que pour Se_compose_de_produits, il faut également une quantité et une unité de mesure ici

Ingredient :
Comme pour les produits, l'énoncé demande une quantité disponible et une unité de mesure de cette quantité

Lieul :
Ici aussi on peut éventuellement ajouter une quantité et son unité de mesure, puisque les ingrédients peuvent avoir des origines diverses
Si on ajoute ces attributs ici, alors on il ne faut pas les ajouter dans ingredient (on ne stocke pas de donnée calculée)
A voir avec le formateur ce qui est souhaité précisément, ou alors proposez les 2 options

N'oubliez pas pour cette partie gauche aussi, d'ajouter des identifiants techniques comme id primaires

[BastGui]

Bonsoir escartefigue!
Merci beaucoup de m'avoir répondu et surtout d'avoir pris du temps pour tout détailler!

J'ai fait quelques modifications, par contre j'ai encore bcp de questions^^' (je vais essayer de me faire comprendre sans les mots techniques ahah)
-Concernant les id primaires, je dois en mettre dans toutes les entités?

-par ex, dans Etape je dois noter, "etape" comme dans le schéma ci joint, ou alors id_etape (ou autre?)

-Du coup si Lieu n'est pas lié avec Recette, c'est possible d'avoir un schéma où il y a une entité isolée du reste? (je ne sais pas si c'est clair)

-Je ne sais pas si c'est bien là que je devais rajouter "quantité" dans l'asso Se_compose_de_produits

- pour les unités (g, kg, L,...) où faut il les ajouter? Ou faire une nouvelle entité Unité ???

- Et pour répondre à la question, pour l'asso Quantité_nécéssaire. Je ne sais pas trop c'était pour "modéliser" la phrase : Enfin, une
recette se compose de produits et/ou ingrédients dans une certaine quantité.

J'espère que mes questions sont claires

Voilà mon nouveau schéma :

[escartefigue]

Concernant les id primaires, je dois en mettre dans toutes les entités?

Dans toutes les entité-type , oui
Dans le MCD vous utilisez des entités-type (symbolisées par des rectangles), les entités seront les occurrences d'entité-type

par ex, dans Etape je dois noter, "etape" comme dans le schéma ci joint, ou alors id_etape (ou autre?)

id_etape est un nom qui peut tout à fait convenir
Ce n'est pas tant le nom de l'attribut qui compte que son type : il s'agit de choisir une colonne technique, dénuée de sens pour garantir sa stabilité dans le temps, et concise pour qu'elle soit économique en CPU
Souvent on utilise "id" en préfixe ou suffixe du nom de l'attribut
Le plus important reste que cet attribut soit de format optimisé (le plus souvent integer, voire bigint si vous devez stocker plus de 4 milliards de valeurs)
Et pour garantir la stabilité, on délègue au SGBD sa valeur en utilisant une colonne de type "identity".

-Du coup si Lieu n'est pas lié avec Recette, c'est possible d'avoir un schéma où il y a une entité isolée du reste? (je ne sais pas si c'est clair)

Ca arrive des fois, par exemple pour des tables d'archivage, mais ici ce n'est pas le sujet. Vous avez fait un lien entre lieu et recette, alors que l'énoncé vous demandait de faire ce lien entre lieu et ingrédients d'une part et lieu et produit d'autre part

- pour les unités (g, kg, L,...) où faut il les ajouter? Ou faire une nouvelle entité Unité ???

A chaque fois que vous avez une mesure (poids, quantité, longueur, durée, etc...) il est préférable d'avoir l'unité de mesure qui va avec
Sauf s'il n'y a aucune équivoque, par exemple si dans l'application toutes les longueurs sont en mêtres, alors vous pouvez économiser l'unité de mesure, mais personnellement, je trouve dommage d'économiser une colonne de quelques caractères (3 suffisent pour un code unité de mesure norme iso) au risque de louper des conversion et d'aditionner des choux avec des carottes

- Et pour répondre à la question, pour l'asso Quantité_nécéssaire. Je ne sais pas trop c'était pour "modéliser" la phrase : Enfin, une
recette se compose de produits et/ou ingrédients dans une certaine quantité.

Pour ce faire, pas besoin de relation supplémentaire, vos associations "se_compose_d'ingredient" et "se_compose_de_produit" suffisent
Seuls les noms de ces associations sont un peux longs, vous pouvez simplifier par exemple par composerP et composerI

J'espère que mes questions sont claires

Pas de souci

Je ne serai pas forcément très actif ce WE, mais vous avez déjà pas mal de pain sur la planche je pense pour corriger tout ça
Pensez aussi à ajouter les types des attributs et leur longueur
Je maintiens que l'énoncé est un peu fantaisiste, outre les latitudes et longitudes qui sont pour le moins inattendues dans des recettes de cuisine , le fait de mettre des quantités disponibles de composants alors que nulle part on n'indique combien on en consomme est également un peu space, mais bon, le formateur est roi

[BastGui]

C'est bien compliqué pour moi tout ça! ahah

J'en arrive à un schéma de la sorte :

Par exemple pour Utilisateur, il faut marquer id_util, nom, prénom.... OU nom, prénom,... suffit?

Le lien entre Lieu et Produit/Ingrédient est-il correcte?

Il faut introduire les unités dans les entités (comme dans le schéma) ou pas??

J'espère que ça commence à être correcte, car je ne vois pas les autres modif à effectuer ^^'

[escartefigue]

Par exemple pour Utilisateur, il faut marquer id_util, nom, prénom.... OU nom, prénom,... suffit?

id_util, nom, prénom....

Le lien entre Lieu et Produit/Ingrédient est-il correcte?

Oui, sauf que vous avez laissé une association "LiueI" inutile car redondante avec "ProvientI" et de plus orpheline
Dans les 2 cas vous pouvez mettre une cardinalité mini coté lieu : un lieu peut être connu dans la base alors qu'aucun produit ni ingrédient ne lui est rattaché

Il faut introduire les unités dans les entités (comme dans le schéma) ou pas??

Oui, et même mieux, il faudrait introduire une nouvelle entité-type "UNITE_MESURE" et faire de nouvelles associations avec cette E-T
Par exemple PRODUIT (id_produit, nom_produit, description, qte...) 1,1 --- Mesurer --- 0,n UNITE_MESURE (id_unite, code_unité, libellé_unité etc...)

J'espère que ça commence à être correcte, car je ne vois pas les autres modif à effectuer ^^'

Oui rassurez vous, c'est déjà nettement plus clair
Par contre n'oubliez pas d'ajouter les types et longueur de chaque attribut
Pour la partie adresses et zones géographique, je ne ferai pas de commentaires, car je ne comprends pas du tout avec l'énoncé ce qu'il faut obtenir
Ou alors c'est parceque c'est tellement abérrant cette histoire de latitude/longitude que je fais un blocage

Concernant le lien ETAPE --INSTRUCTION, je vous recommande d'utiliser l'identification relative matérialisée par des parenthèses, ce qui donne :
ETAPE 1,n --- Inclure --- (1,1) INSTRUCTION
En effet, si vous utilisez l'identification relative, alors le modèle physique génèrera une PK pour la table INSTRUCTION composée de id_etape + id_instruction, ce qui permettra d'organiser les index de sorte à ce que les instructions qui concernent une même étape soient sur une même page de données (et du coup en une seule lecture physique, on accède à toutes les instructions)
Ici, on entre dans des considérations liées aux performances de la base de données. Le MCD est en principe construit hors considérations de cet ordre, mais dans les faits, ce n'est pas tout à fait le cas.

N'oubliez pas d'ajouter la quantité et l'unité de mesure dans la relation "ComposerI"

[BastGui]

Bonsoir, bonsoir,

Alors j'ai fait les modifications, mais pour ce qui est des ( ) pour ETAPE -- INSTRUCTION, sur AnalyseSI que j'utilise pour modéliser, il n'y a que 4 possibilités pour les cardinalités : 0,N, 0,1, 1,N, 1,1....

Et pour : UNITE_MESURE (id_unite, code_unité, libellé_unité etc...) à quoi correspond code_unité, etc ?? où sont les g, L, ..??

Et pour finir, dans l'asso ComposerP, il y a quantitéP et unitéP?? si c'est le cas, je dois l'enlever dans l'entité Produit ??

Je crois que c'est mes dernières questions :-)

[escartefigue]

Bonsoir, bonsoir,
Alors j'ai fait les modifications, mais pour ce qui est des ( ) pour ETAPE -- INSTRUCTION, sur AnalyseSI que j'utilise pour modéliser, il n'y a que 4 possibilités pour les cardinalités : 0,N, 0,1, 1,N, 1,1....

Je ne connais pas AnalyseSI, mais sur PowerAMC par exemple, il suffit de cocher une case pour indiquer qu'il s'agit d'une relation identifiante

Et pour : UNITE_MESURE (id_unite, code_unité, libellé_unité etc...) à quoi correspond code_unité, etc ?? où sont les g, L, ..??

Code unité : g, libellé : gramme
Code unité : l, libellé : litre
Code unité : cm3, libellé : centimètre cube
etc...

Et pour finir, dans l'asso ComposerP, il y a quantitéP et unitéP?? si c'est le cas, je dois l'enlever dans l'entité Produit ??

Non, il faut les 2 :
Dans Produit, il s'agit de la quantité totale disponible, et de son unité de mesure comme demandé dans l'énoncé
Dans la relation, il s'agit de la quantité requise d'un produit pour une recette, et son unité de mesure

[BastGui]

D'accord très bien, je demanderai à mon prof pour les ( )

Ca marche je commence à comprendre tout ça^^ (plus ou moins) et du coup... il faut lier Unite_mesure avec ComposerI, ComposerP et Mesurer ou seulement avec Mesurer???

[escartefigue]

il faut lier Unite_mesure avec ComposerI, ComposerP et Mesurer ou seulement avec Mesurer ?

Il faut supprimer la relation "Mesurer" car c'est deux relations qu'il faut et non une relation ternaire dans ce cas

Si vous voulez faire simple :

Créez une relation
PRODUIT 1,1 --- Mesurer1 --- 0,n UNITE_MESURE
Et une autre relation
INGREDIENT 1,1 --- Mesurer2 --- 0,n UNITE_MESURE

Et utilisez des règles selon lesquelles
L'unité de mesure utilisée entre Produit et Recette sera la même que celle du produit, du coup plus besoin de l'unité dans la relation
L'unité de mesure utilisée entre Ingrédient et Recette sera la même que celle de Ingrédient, du coup plus besoin de l'unité dans la relation

[SQLpro]

Dans une recette certaines étapes peuvent être faites en parallèle. Par exemple pendant la cuisson de la volaille à la rôtissoire, épluchage et cuisson des légumes, élaboration de la sauce...
par conséquent votre entité étape n'est pas linéaire (liste chainée) mais arborescente !

A +