Discussion :

[l0vers0n]

Bonjour,

je suis étudiant en info en deuxième.
Il se fait que je dois réaliser un projet pour mon cours de base de donnée mais je suis assez confus étant donné que j'ai choisi un projet assez difficile à concevoir.

Je viens ici afin de chercher un peut d'aide.

voici l'exposé du problème:

Il s'agit d'une plate-forme de gestion d'artistes et de clients d'une boite de comm.

Première partie:
Il doit être possible à intrnaute de visualiser des pages statiques du site web( pages parlant de l'entreprise)
Il doit être possible que l'internaute visualise les infos sur n'importe quel artiste
Il doit être possible à l'internaute de s'inscrire à une news letter
IL doit être possible à un internaute de se connecter s'il à été enregistré et confirmé au préalable.
Pourquoi confirmé? car tout le monde ne peut s'y inscrire donc toute inscription devra être confirmée par un administrateur.
___________________________________________________________
Il y a différents types d'utilisateurs enregistrés: les clients (qui viennent booker les artistes), les artistes que la boite manage, un maganer (qui peut modifier les infos de tous les artistes que la boite manage et ceux qu elle ne manage pas mais qu elle propose aussi ex: manage un DJ mais propose en plus un artist qu'elle peut avoir par une maison de production)
En gros, l'agence est la propre maison de prod des artistes qu'elle manage.

____________________________________________________________

tous les artistes proposés disposent: d'un calendrier, une maison de prod, des infos sur lui (nom, prenom etc)

Les artistes que l'on manage peuvent modifier leur calendar et leurs infos. Le manager peut altérer ceux des artistes que l'on ne manage pas.


Un client, une fois identifié peut visualiser les calendriers des artistes et choisir de faire un request form pour un ou plusieurs artistes au manager.
Le request form est une proposition que le client fait à l'agence pour un ou plusieurs artistes, pour une ou plusieurs dates ou l'artiste est libre (dans son calendar)
Le Manager traite le request form et rajoute certaines infos pour constituer l'offer form et l'envoyer à la maison de prod.

La maison de prod vas renvoyer un artist engagement agreement au manager qui est un contrat entre l'agence et la maison de prod et un rider qui est un document spécifique à l'artist.

Le manager vas envoyer Le rider de l'artist et un contrat type au client et une facture.
Une fois la facture payée (Le manager confirme la reception de payement ) et le contrat retourné signé (Le manager confirme la reception), une alarme ( la période de rappel est définie dans les configurations de l'artist) est mise sur une date du calendar de l'artist managé pour lui rappeller l'événement, et sur le calendar du manager pour les artistes non managés.
_____________________________________________________________


L'administrateur à les mêmes fonctionnalitées que le manager mais peut en plus editer les pages statiques du site.

Merci pour votre aide très précieuse.

Greg

[Tommy31]

Sur quoi bloques-tu ? Tu en es à quel point ?

[l0vers0n]

Sur quoi bloques-tu ? Tu en es à quel point ?

Je ne sais pas trop comment réaliser mes tables et les relations qu'il doit y avoir entre celles ci et ce de manière optimale...

[CinePhil]

Dans ton texte, je vois :
- des internautes ;
- des artistes ;
- des clients ;
- un administrateur ;
- un ou des manager(s).

Il y a différents types d'utilisateurs enregistrés: les clients (qui viennent booker les artistes), les artistes que la boite manage, un maganer

Il semble que toutes ces catégories de personnes soient les internautes mentionnés en premier non ?

Il semble donc pour commencer qu'il faille mettre en oeuvre l'héritage de internaute (ou utilisateur) vers artiste, client, administrateur, manager.

Règles de gestion :
- Un artiste est un utilisateur et un utilisateur peut être un artiste.
- Un client est un utilisateur et un utilisateur peut être un client.
...

MCD :
Artiste -(1,1)----Etre----0,1- Utilisateur
Client -(1,1)----Etre----0,1-------|
Manager -(1,1)----Etre----0,1---|

Ensuite, ton texte contient des notions de possibilités d'action pour les différents types d'utilisateurs.
Tu peux gérer ça en BDD ou par l'application. En BDD, ça donnerait une règle de gestion du style :
- Une catégorie d'utilisateur a de 1 à plusieurs droits d'utilisation sur le logiciel.

Il y a ici deux solutions.
La première consiste à typer l'entité Utilisateur, ce qui alourdit le schéma de l'héritage précédemment élaboré, et à accorder les droits au type d'utilisateur :
Utilisateur -1,1----Typer----0,n- TypeUtilisateur -1,n----Accorder----0,n- Droit

La seconde consiste à accorder les droits directement aux types des utilisateurs (artiste, client...), ce qui multiplie l'association Accorder par le nombre de types :

Droit -0,n----Accorder----1,n- Artiste -(1,1)----Etre----0,1- Utilisateur
|--------0,n----Accorder----1,n- Client -(1,1)----Etre----0,1-------|
|--------0,n----Accorder----1,n- Manager -(1,1)----Etre----0,1---|

Voilà un début de réflexion sur ton énoncé. Le principe général est d'écrire des règles de gestion comme celles que j'ai données ci-dessus puis à les transformer en morceaux de schéma MCD que tu peux ensuite raccorder.

[l0vers0n]

tout d abord merci pour votre réponse.

J'en ai pris bonne note et je suis partis sur vos conseils pour la realisation.

Je suis donc arrivé au schéma suivant:



pourriez vous me le commenter. si besoin je peux fournir le code sql.

Merci beaucoup