conception de base de données de recyclage

Question

J'ai du mal à trouver une conception adéquate pour conserver les données de recyclage. Les données sont collectées sur un cycle de trois mois, pour chaque semaine de ce mois. afin que les données se présente comme suit (ils recueillent les données actuellement dans Excel en ce moment):

Month 1  | Plastic  | Metal | Newspaper | Cardboard | Paper 
--------------------------------------------------------------------------------- 
    Measurement: | (x) 19 Gal | 19 Gal | 19 Gal | 19 Gal | 19 Gal 
       | 36 Gal  | 36 Gal | 36 Gal | 36 Gal | 36 Gal 
       | Lbs   | Lbs | Lbs  | Lbs  | Lbs 
       | Other:(txt) | Other | Other  | Other  | Other      
--------------------------------------------------------------------------------- 
    Week 1  | 1 
    Week 2  | 
    Week 3  | 
    Week 4  | 
    Week 5  | 2 
---------------------------------------------------------------------------------- 
    Total (Lbs) | Z 

Dans cet exemple, le total (Z) serait une conversion de 3 19 gallons bacs à lbs

La partie qui me fait mal à la tête est chaque produit recyclable a plusieurs attributs qui leur sont attachés, donc le plastique a une taille de bac, comment il a été recyclé, etc ....

J'ai lu sur EAVs and class Table inheritance, mais ils ne vous sentez pas 'bien' pour ce problème. Merci d'avance.

Answer 1

Pour commencer, s'il vous plaît me dire que vous n'utilisez pas "1 semaine", etc., jamais, mais un Intervalle (ie date de début int, date de fin int). Maintenant, quels sont vos problèmes avec Table Inheritance? Cela ressemble à un exemple classique. La classe de base/table serait produit recyclable avec un minimum d'attributs communs ... est-ce le problème? Vous ne trouvez rien "en commun", à part le nom?

Qu'en est-il de l'unité de mesure? C'est à dire. une référence à un autre tableau détaillant Kg., Gallons, pied cube, etc.?

Peut-être qu'un fanion "Dangereux"? A partir de là, vous pouvez spécialiser "Plastique" en ajoutant un champ pour "Méthode de recyclage". Qui pointe vers un autre tableau répertoriant les alternatives disponibles. "Taille du bac" serait une unité de mesure? Devrait-il s'agir d'un attribut de «classe» de base (c'est-à-dire que tous les plastiques sont mesurés en fonction du poids) ou devrait-il dépendre de différentes choses? (c'est-à-dire le type de plastique? Type de point de collecte?)

Il est parfaitement correct de ne pas avoir beaucoup dans la table de base en dehors d'un ID numérique et quelques champs descriptifs, de toute façon.

Answer 2

Ne veux-tu pas quelque chose comme:

Month | Recycling_Type | Recycling_ID

---

Week1, Plastic, 2342
Week2, Plastic, 2343
Week2, Metal, 4

ont ensuite une table séparée pour chaque type de recyclage:

Plastic
ID, Bin Size

---

2342, 5
2343, 6

etc

Answer 3

Votre boîtier ressemble à une instance du motif de conception Gen-Spec. Gen-spec est familier aux programmeurs orientés objet via la hiérarchie de superclasse-sous-classe. Malheureusement, les introductions à la conception de base de données relationnelle ont tendance à sauter sur la façon de concevoir des tables pour la situation Gen-Spec. Heureusement, c'est bien compris. Une recherche sur le Web sur la «Spécialisation de la généralisation de la base de données relationnelle» donnera plusieurs articles sur le sujet. Certains de vos hits seront des questions précédentes ici sur SO.

L'astuce réside dans la façon dont le PK des tables de sous-classes (spécialisées) est affecté. Ce n'est pas généré par une sorte de fonction de numérotation automatique. Au lieu de cela, c'est une copie du PK dans la table de superclasse (généralisée), et est donc une référence FK à celle-ci. Ainsi, s'il s'agissait de véhicules, camions et berlines, chaque camion ou berline aurait une entrée dans la table des véhicules, les camions auraient également une entrée dans la table des camions, avec un PK qui est une copie de la PK correspondante. dans la table des véhicules. De même pour les berlines et la berline. Il est facile de déterminer si un véhicule est un camion ou une berline en faisant simplement des jointures, et vous voulez généralement joindre les données dans ce genre de requête de toute façon.