Demande aide/correction MCD studio de création audiovisuelle

Bonjour,

Je travaille actuellement sur un MCD pour le site d'un studio de création audiovisuelle, graphique.

Ce studio propose aussi du matériel a la location ainsi que le studio lui même, je dois donc pouvoir lister tous les différents matériels et les trier par marque, type... Les utilisateurs doivent pouvoir voir la disponibilité du studio sur un calendrier, idem pour le matériel. Il peuvent faire une demande location en précisant les date/horaires souhaitées, qui sera validée ou non par l'administrateur. Ensuite l'administrateur pourra ajouter les créneaux réservés au calendrier concerné. La partie gestion du calendrier me parait vraiment délicate (a mon humble niveau).

Concernant le MCD, je me demande si ce que j'ai fait jusqu'a présent est correct. Et comment gérer les différents calendrier (studio et matériels). Aussi, j'utilise le logiciel JMerise et ce dernier ne me permet pas d'avoir plusieurs relations du même nom. Y'a t'il une convention pour les nommer? Pour les photos j'ai plusieurs relations (actus, matériels, clients, projets). J'ai mis pour l'instant un Entité studio mais je pense que je devrais plutôt le compter dans l'entité matériel et la renommer.

J’espère avoir été assez clair dans mes explications.

Merci pour votre aide.
Cordialement


R001: Un matériel peu avoir une et une seule marque.
R002: Une marque peut avoir zéro ou plusieurs matériels.

R003: Un matériel peut être rattaché a une ou plusieurs catégories.
R004: Une catégorie peut être rattachée a zéro ou plusieurs matériels.

R005: Un matériel peut relever de un ou plusieurs type de matériel.
R006: Un type de matériel peut relever de un ou plusieurs matériels.

R007: Un utilisateur peut avoir un seul rôle.
R008: Un rôle peut avoir zéro ou plusieurs utilisateurs.

R009: Un utilisateur peut demander une ou plusieurs demande de location de matériel.
R010: Un matériel peut être demandé a la location par un ou plusieurs utilisateurs.

R011: Un utilisateur peut valider une ou plusieurs demandes de réservations.
R012: Un demande de location peut être validée par un seul utilisateur.

R013: Un matériel peut être concerné par une ou plusieurs photos.
R014: Une photo peut être concernée par un seul matériel.

R015: Une actualité peut être concernée par une ou plusieurs photos.
R016: Une photo peut être concernée par zéro une seule actualité.

R017: Un client peut être concerné par une seule photo (logo).
R018: Une photo (logo) peut être concernée zéro ou un seul client.

R019: Un projet peut être concerné par une ou plusieurs photos.
R020: Un photo peut être concernée par un seul projet.

R021: Un projet peut dépendre de une ou plusieurs activités.
R022: Une activité peut dépendre de zéro ou plusieurs projets


Pièce jointe 641549

Bonsoir,

Citation:

---

Envoyé par GasconWarrior

Aussi, j'utilise le logiciel JMerise et ce dernier ne me permet pas d'avoir plusieurs relations du même nom. Y'a t'il une convention pour les nommer?

---

Je ne sais pas pour JMerise, mais avec Looping vous pouvez utiliser le même nom conceptuel à condition que le nom logique soit unique ; en effet, lors de la génération du MLD, une association pouvant devenir une table, les noms doivent être différents.
Vérifiez si JMerise autorise la même chose.

Bonne continuation.

Merci pour vos conseils, je vais essayer Looping.

Bonjour,

Avec JMerise , la redondance des noms des relations est autorisée dans le MCD.

Bonne journée

Bonjour GasconWarrior

Ces règles requièrent des explications supplémentaires :

Citation:

---

Envoyé par GasconWarrior

R009: Un utilisateur peut demander une ou plusieurs demande de location de matériel.
R010: Un matériel peut être demandé a la location par un ou plusieurs utilisateurs.

R011: Un utilisateur peut valider une ou plusieurs demandes de réservations.
R012: Un demande de location peut être validée par un seul utilisateur.

---

Est-ce que tout utilisateur peut valider une demande ou bien certains utilisateurs seulement (ayant un rôle particulier peut-être ?)
Est-ce que l'utilisateur qui valide une demande peut être le même que celui qui a émis la demande ?

Par ailleurs, la demande est un acteur de votre modèle, elle doit faire l'objet d'un type d'entité ayant pour attributs une date de demande, un date de début de réservation, une date de fin prévue, une date de fin réelle, etc. Cette demande sera en relation avec un ou plusieurs matériels (règles de gestion à préciser), un et un seul utilisateur demandeur et un et un seul utilisateur valideur et éventuellement une contrainte d'exclusion si valideur et demandeur sont obligatoirement des personnes différentes.
Il faudra savoir ensuite si plusieurs demandes pour un même matériel peuvent être émises sur des périodes chevauchantes (auquel cas, on prendra garde de n'en valider qu'une seule) ou pas.

Concernant les typologies (marques, catégories, type de materiel...) il est pratique d'avoir un attribut CODE de type char court (ex CHAR(4)).
C'est en effet plus pratique de rechercher un code dans une liste qu'un libellé, le libellé sera récupéré automatiquement par l'application à partir du code.
Ce code fera l'objet d'une contrainte unique (mais ne se substitue pas à la PK de type integer).

Je m'arrête là pour cette première lecture rapide de votre MCD, à plus tard :)

Bonjour,
Désolé pour ma réponse un peu tardive.
J'ai été éloigné de mon ordinateur durant une semaine.
J'ai un peu retravaillé le MCD depuis mon post.

Seul l'admin du site peut valider une demande de réservation.
L'admin dans un cas précis pourrait être amené a demander et valider une réservation (une demande de réservation prise par téléphone).

Je n'avais pas pensé au chevauchement éventuel de certaines demandes. Je vais le prendre en compte (un message au moment de la validation après vérification en BDD pourrait suffire?).
Pour le CODE je vais le retravailler aussi, je ne connaissais pas vraiment son utilité.

Merci pour l'aide.:plusser:

Pièce jointe 642372Pièce jointe 642373

Quelques remarques supplémentaires

Typage et longueur des données

• Pour les montants, il est préférable d'utiliser le type DECIMAL plutôt que le type FLOAT : FLOAT a une précision décimale approximative, ce qui peut poser des problèmes en comptabilité ou quand il faut calculer un montant à facturer par exemple.
• Pour les chaînes de caractères, il est préférable de remplacer le type (LONG/MEDIUM/TINY) TEXT qui n'est pas un type standard SQL par un CHAR, VARCHAR, NCHAR ou NVARCHAR selon le besoin.
• Pour les noms, prénoms et numéro de téléphone, varchar(255) c'est beaucoup trop
• Pour l'adresse courriel, 255 caractères est insuffisant. Il faut respecter la norme de codification des adresses courriel et, de préférence, externaliser le domaine (comme ça, si un domaine change, on ne le modifie qu'une seule fois). Voir ICI pour la structure d'une adresse courriel

Entité-type réservation
A-t-on besoin de gérer les réservations à l'heure près ? La date ne suffit-elle pas ?
Si le besoin est avéré, il est préférable de n'avoir qu'une seule colonne date_heure_début et une seule colonne date_heure_fin toutes les deux de type timestamp, les contrôles de chevauchements en seront facilités.
Sinon, supprimez simplement les attributs heure de début et de fin


Règles de gestion
Il en manque quelques unes, par exemple, rien n'est précisé concernant les clients vis à vis des projets, ni des projets vis à vis des activités.
À minima, chaque "patte" d'association doit être justifiée par une règle, il peut y avoir des règles supplémentaires (inclusion, exclusion, domaine de valeurs...)

J'ai corrigé mon MCD selon vos conseils.
Je comprends un peu mieux l'importance des types de données. Pour la taille des adresses mail j'ai lu tout et son contraire sur le web je me suis donc fié a la documentation que vous m'avez donné. Pour l'externalisation du domaine, je ne suis pas sur de comprendre. Il faut parser les adresses mail pour en extraire le domaine?

Au sujet des réservations je vais en rediscuter car je ne suis pas sur que ce soit une bonne idée de gérer des réservations à l'heure près. En cas de retard sur un retour de matériel le client suivant serait pénalisé et le loueur embêté. Je vais proposer journée ou demi journée (ça me facilitera la tache par la même occasion).

Merci encore.
Vos conseils me font apprendre.

Pièce jointe 642603


Pièce jointe 642602