[relations] schéma ok ou à modifier?

[Zebeber]

Bonjour,
je voudrais me faire un petit prog pour ma gestion de dvd, à qui je les prête, quand on me les rend, ...
Mon prog ne fera que gérer tout ça, mais je voudrais faire un schéma de base de données évolutive.
Je voudrais en fait, que mon prog puisse évoluer, et donc ma base de données doit s'y préparer.
L'évolution future de mon prog serait de pouvoir gérer des types d'abonnement pour les clients (mensuel, annuel, carte de 25 locations, promotions, ...)
C'est à dire que plus tard, je dois pouvoir lier un abonnement à un client, le résilier, ...

Voici le schéma de mes tables et relations à l'heure actuelle.
J'aurais voulu savoir si mon principe de relations est correct pour la gestion des abonnements et des tarifs, quels champs, voire quelles tables devrais-je ajouter pour que ma base de données soit bien complète?



Pouvez-vous me dire aussi s'il faudrait faire d'autres changements pour améliorer (ou compléter) ma base de données?

D'avance merci beaucoup

[Luc Orient]

Un film appartient à un seul genre ou plusieurs ?

PS. Pour les questions sur la conception, il me semble que c'est plutôt dans le forum "Langage SQL" qu'il faut les poser ...

[Médiat]

Envoyé par Luc Orient

PS. Pour les questions sur la conception, il me semble que c'est plutôt dans le forum "Langage SQL" qu'il faut les poser ...

C'est plutôt le forum Modélisation.

Zebeber :
Questions à te poser :

• Tu as fait une table d'association entre Film et Genre, afin de pouvoir dire qu'un film appartient à plusieurs genres, dans ce cas, à quoi sert l'attribut Genre de l'entité Film ?
• Est-ce que tu veux gérer plusieurs copies de chaque film ?
• Dans ce cas faut-il gérer individuellement chaque exemplaire (pour gérer l'usure et le remplacement)
• Ne faudrait-il pas pouvoir gérer plusieurs acteurs pour un film ; le s que tu as mis au nom de l'attribut "Acteurs" laisse penser que oui, mais alors tu as choisi la pire solution, il vaudrait mieux créer une entite ACteur et une table d'association
• Est-ce normal de ne pas gérer les langues disponibles ?
• Ton modèle ne permet de gérer qu'un seul abonnement par client (ce qui implique de perdre l'historique)
• etc.

[Luc Orient]

Envoyé par Médiat

C'est plutôt le forum Modélisation.

Définition du forum Langage SQL :
"Entraide sur le langage SQL et sur les questions liées à la conception de schéma (DDL)."
J'ai eu la faiblesse de penser que cette question relevait de la conception de schéma. Mais sans doute me suis-je trompé ...

[Médiat]

Luc : là on est au niveau du MCD, donc de la modélisation, pas du langage SQL (dont le DDL fait partie).

[Zebeber]

Envoyé par Médiat

C'est plutôt le forum Modélisation.

Zebeber :
Questions à te poser :

• Tu as fait une table d'association entre Film et Genre, afin de pouvoir dire qu'un film appartient à plusieurs genres, dans ce cas, à quoi sert l'attribut Genre de l'entité Film ?

Heu, à rien, excusez-moi...

• Est-ce que tu veux gérer plusieurs copies de chaque film ?
• Dans ce cas faut-il gérer individuellement chaque exemplaire (pour gérer l'usure et le remplacement)

Oui, éventuellement, dans la version future du prog.
Mais dans ce cas là, comment faire? Ajouter simplement un champ "Qté disponible"? Qu'est-ce que ça implique comme modifications?

Ne faudrait-il pas pouvoir gérer plusieurs acteurs pour un film ; le s que tu as mis au nom de l'attribut "Acteurs" laisse penser que oui, mais alors tu as choisi la pire solution, il vaudrait mieux créer une entite ACteur et une table d'association

Oubli de ma part. Je l'avais noté sur la version papier de mon schéma à étbalir, mais je ne l'ai pas mise dans access. Bien vu, et merci.

Est-ce normal de ne pas gérer les langues disponibles ?

Ok, je les mets, mais avec une table langue et une table d'association?
Je vais en profiter pour ajouter le type de son, si bonus ou non il y a, ...

Ton modèle ne permet de gérer qu'un seul abonnement par client (ce qui implique de perdre l'historique)

Que veux-tu dire par là? Comment faire pour gérer plusieurs abonnements? Comment enregistrer un éventuel historique par client (table, fichier, ...?)?

Merci déjà de tes précieux conseils

[Médiat]

Envoyé par Zebeber

Mais dans ce cas là, comment faire? Ajouter simplement un champ "Qté disponible"? Qu'est-ce que ça implique comme modifications?

Un attribut "Quantité disponible" permet de prêter plusieurs exemplaires mais pas de les suivre individuellement (l'usure n'est pas la même sur tous les exemplaires).

Envoyé par Zebeber

Ok, je les mets, mais avec une table langue et une table d'association?

Oui, et avec un flag pour préciser s'il s'agit d'une langue parlée ou pour les sous-titres.

Envoyé par Zebeber

Que veux-tu dire par là? Comment faire pour gérer plusieurs abonnements? Comment enregistrer un éventuel historique par client (table, fichier, ...?)?

Un abonnement ce n'est pas seulement un client et un tarif, il doit y avoir une date de début et une date de fin, un prix réel (en cas de remise exceptionnelle) etc... En mettant la date de début (ou un N° d'ordre si un même client peut souscrire plusieurs abonnement en même temps) dans la clé, tu peux gérer l'historique...

[Zebeber]

Ok, j'ai bien compris, sauf pour les abonnements.
Suis pas du tout pro dans la création de base de données.
N'aurais-tu pas un exemple concret de table pour la gestion des abonnements?
J'ai peur de ne pas comprendre.

[Zebeber]

Je me permet de redemander si un bon exemple de gestion d'abonnements n'existe pas, car je n'en sors pas de trop.

Merci d'avance