Discussion :

[Sharym]

Bonjour à tous, aillant quelques soucis en archi de bdd je souhaiterai un peu de votre aide et vos conseils svp

Le sujet:

Je souhaiterai avoir une table mère Periode (id, nom, couleur(string)) et deux table enfants Pannuelles et Phebdos héritant des champs de la table mère et aillant toutes les deux un champs contenant une liste de date pour chaque entrée:
Exemple : 1 | Fériés| Gris | "01/05/2015", "08/05/2015" etc..

Mes problèmes :

Après plusieurs recherches je ne sais pas trop comment exprimer le notion d'héritage.. il me semble qu'il faut faire une ForeinKey mais je ne vois pas comment.
Ensuite je ne sais pas comment créer/exprimer mon champs où il y aura la possibilité de rentrer une liste de valeurs..

Je vais sûrement me faire fouetter mais j'implore votre aide d'expert

[escartefigue]

Bonjour,

Il faut commencer par communiquer le MCD avant d'aborder le MPD

[Sharym]

Il faut commencer par communiquer le MCD avant d'aborder le MPD

Justement je ne sais pas trop comment représenter ça.
Je pars du DC suivant :




Mais je n'ai pas vraiment d'idée pour représenter les liens d'héritage et les champs "list".



EDIT : Dans mon appli (J2E), je dois récupérer ces périodes hebdos et annuelles pour les afficher sur un calendrier en colorant la liste de date correspondant à la dite période.

Merci d'avance

[escartefigue]

Ce schéma n'est pas de niveau conceptuel, le MCD représente les entités, les relations et les cardinalités et non les tables
C'est en fonction des cardinalités entre entités et relations et que l'on déduit les clef étrangères qui seront créées dans les tables résultantes et donc dans le MPD

[Sharym]

En dehors des cardinalités le mcd est pareil que le diagramme de classe (deux entités qui héritent de la mère Periode; une période peut contenir 0 à n fille) mais je voudrais juste savoir comment on modélise de l'héritage et comment on représente une liste .. je souhaite juste savoir la base je saurais me débrouiller pour les détails.

[CinePhil]

je ne sais pas trop comment exprimer le notion d'héritage.. il me semble qu'il faut faire une ForeinKey mais je ne vois pas comment.

Commençons par reprendre votre contexte :

Je souhaiterai avoir une table mère Periode (id, nom, couleur(string)) et deux table enfants Pannuelles et Phebdos héritant des champs de la table mère et aillant toutes les deux un champs contenant une liste de date pour chaque entrée:
Exemple : 1 | Fériés| Gris | "01/05/2015", "08/05/2015" etc..

Je déduis de ceci ce qui suit...

Règles de gestion :
Une période annuelle est une période et une période peut être une période annuelle.
Une période hebdomadaire est une période et une période peut être une période hebdomadaire.

MCD :
periode_annuelle -(1,1)----être----0,1- periode
periode_hebdo -(1,1)----être----0,1---------|

Tables :
te_periode_prd (prd_id, prd_nom, prd_couleur, [propriétés communes à toutes les périodes]) => La couleur devrait être externalisée dans une table des couleurs.
th_periode_annuelle_pan (pan_id_periode, [propriétés spécifiques aux périodes annuelles])
th_periode_hebdo_phb (phb_id_periode, [propriétés spécifiques aux périodes hebdo])

Les tables filles ont pour clé primaire la clé étrangère référençant l'identifiant de la période.

Avant que vous fassiez une grosse erreur de modélisation, j'aimerais revenir sur un point qui cloche dans votre description :

aillant toutes les deux un champs contenant une liste de date pour chaque entrée:
Exemple : 1 | Fériés| Gris | "01/05/2015", "08/05/2015" etc.

L'information contenue dans une colonne de table, donc dans une propriété de l'entité type ou de l'association type du MCD, doit être atomique. Donc on ne stocke pas plusieurs dates pour une seule période dans une seule colonne.

[Sharym]

Ah merci pour la représentation plus claire, j'avais la globalité mais je ne savais pas comment et où représenter les clés étrangères/primaires..

En effet j'ai mal décrit mon soucis.. lorsque je vais représenter une période sur mon appli, elle aura un nom, une couleur (j'ai en effet ajouter une table pour les couleurs) et donc une liste de jours.. par exemple une période "Fériés" aura : le 01/05/2015, le 08/05/2015, etc.. Et je ne sais pas du tout comment représenter cela dans la base sachant ce que vous avez dit sur les entités atomiques.

[CinePhil]

Et bien appliquons la même méthode...

Règle de gestion :
Une période peut couvrir plusieurs jours et un jour peut être couvert par plusieurs périodes.

MCD :
période -0,n----couvrir----0,n- jour

Tables :
te_periode_prd (prd_id, prd_id_couleur...)
te_jour_jur (jur_id, jur_date...)
tj_prd_couvrir_jur_pcj (pcj_id_periode, pcj_id_jour)

[Sharym]

Ah d'accord, mais n'est il pas possible de faire autrement que créer une table jour? Parce que je bosse avec des entités JPA (java persistant api) donc un type de période = une entité jpa = une classe, ainsi mon entité PeriodHebdo peut avoir un attribut de type list<date>

[fsmrel]

Bonsoir,

Ce schéma n'est pas de niveau conceptuel, le MCD représente les entités, les relations et les cardinalités et non les tables
C'est en fonction des cardinalités entre entités et relations et que l'on déduit les clef étrangères qui seront créées dans les tables résultantes et donc dans le MPD

Sharym a proposé un diagramme de classes (DC), on est donc bien au niveau conceptuel, il a modélisé des classes et non pas des tables.

Au sujet d'un abus de langage fréquent : je rappelle que dans un MCD on modélise des types d’entités (entités-types) et non pas des entités : une entité est une instance d’un type d’entité, nuance.


.

[CinePhil]

je bosse avec des entités JPA (java persistant api) donc un type de période = une entité jpa = une classe, ainsi mon entité PeriodHebdo peut avoir un attribut de type list<date>

Ce n'est pas l'application qui décide du modèle de données !
Elle l'interroge, met à jour les données, mais ne touche pas à sa structure qui doit être correctement modélisée si on veut éviter les gros problèmes avec la montée en charge.

Une classe de l'application n'est pas forcément égale à une table de la BDD. Dans l'idéal, l'applciation ne devrait interroger que des vues (et là, une classe métier de l'applciation peut correspondre à une vue de la base de données) et utiliser des procédures stockées de la BDD pour mettre à jour les données. C'est ce qu'on appelle le développement en base de données épaisses.

[Sharym]

Ah oui donc la table comportant les id_period et les id_jours serait une vue..du coup comme ça quand je pioche dedans en fonction d'un id_period j'ai tous les jours qui sont assignés ?
Très bonne idée si j'ai bien compris; merci beaucoup !

[CinePhil]

Euh... pas tout à fait !

Exemple de vue pour une période "jours fériés" :

Code SQL :

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

1
2
3
4
5
6
CREATE VIEW v_jours_feries AS
SELECT j.jour_date AS jour,
FROM te_jour_jur, j
INNER JOIN tj_prd_couvrir_jur_pcj pcj ON pcj.pcj_id_jour = j.jur_id
	INNER JOIN te_periode_prd p ON p.prd_id = pcj.pcj_id_periode
WHERE p.prd_nom = 'Jours fériés'

Et une vue s'interroge comme une table. Quels sont les jours fériés de 2015 ?

Code SQL :

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

1
2
3
4
SELECT jour
FROM v_jours_feries
WHERE jour BETWEEN '2015-01-01' AND '2015-12-31'
ORDER BY jour

[Sharym]

Ah.. mais je comprends pas trop le résultat que ça va donner avec vos abréviations?
De plus j'ai bien compris que je dois interroger une vue si je veux avoir la liste des jours correspondant à une période mais dans ce cas je ne comprends pas trop ce que je dois mettre comme champs dans mes périodes? le champs correspondant aux jours :/


Merci de votre patience et aide en tout cas

[Sharym]

Plus de réponse ? :/

[CinePhil]

Qu'est-ce que vous ne comprenez pas ?

[Sharym]

Et bien si je dois créer une vue permettant de lister les jours d'une période dans ce cas que dois-je mettre comme champs dans mes tables filles (pour les jours de cette période) ? Si ma table fille periode_hebdo n'a plus de champs concernant les jours d'une période, alors elle est identique à la table mère.

[CinePhil]

Peut-être que vous n'avez tout simplement plus besoin d'héritage de table si vous n'avez pas de propriétés particulières à chaque type de période.
Le modèle que j'ai décrit dans mon message #8 n'est-il pas suffisant ?

Quelles différences y a t-il entre les périodes annuelles et les périodes hebdomadaires ? Ou d'autres types de périodes ?

[Sharym]

Ah peut être en effet.

Alors voici mon cahier des charges :

Période annuelle : - Un nom; - Une couleur; - Un booléen pour dire si elle est reproductible tous les ans (comme les jours fériés 01/05 08/05 etc); - Une liste de jour mélangeant date et énumération de jour de la semaine

Un exemple de période annuelle : les vacances scolaire :
"Vacances scolaire", "Bleu", Vrai, Du 01/07 au 05/09 du lundi au vendredi (approximativement)

-----------------------------------------------
Période hebdomadaire : - Un nom; - Une couleur; - Une liste de jour type énumération de jour de la semaine

Un exemple de période annuelle : les semaines :
"Semaine", "Rouge", {Lun, Ma, Me, Je, Ve}.


-------------------------------
C'est pour ça que je suis parti d'un diagramme de classe aillant un héritage d'une classe mère. Cependant devant utiliser une base de données pour stocker les infos des périodes créés ( j'utilise JPA ), j'ai vraiment du mal à agencer tout ça



Merci.

[SQLpro]

Une remarque d'intérêt général...

ON NE MODÉLISE PAS UNE PÉRIODE AVEC DEUX DATES... On modélise une période avec une date de début et une durée en unité de temps.

Code :

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

1
2
DATE_DEBUT  DATE,
DUREE_JOUR INT (CHECK VALUE >=0)

En effet, la modélisation avec 2 dates possèdes plusieurs inconvénients :

• la date de fin NULL (en modélisation le NULL est interdit. Quelle date de fin mettre ?) Avec la solution date/durée mettre 0
• la possibilité d'erreurs de saisie : par exemple si les dates sont inversées => contrainte complexe portant sur 2 colonnes alors qu'avec date/durée il faut simplement que la durée soit >=0
• mise à jour des données... Il est probable que de nombreuses modification portent rarement sur à la fois la durée et la date de début. Si c'est un décalage de date (cas des planning prévisionnels, des réservations vacances...etc) le couple date/durée n’exige que la mise à jour de la date... Si c'est une durée modifiée, vous ne bougez que la durée...
• un certain nombre de requêtes sont simplifiées, notamment pour les calculs de durée

etc...

Enfin pour présenter vos données aux utilisateurs, il suffit de faire une vue qui montre les deux dates... Sur certains SGBDR vous pouvez aussi utiliser une colonne calculée persistante.

A +