Discussion :

[Doremus]

Bonjour, je viens vers vers vous afin de répondre a une question simple :

Une clé primaire doit-elle toujours être composée de clé étrangère ? Si oui, pourquoi ?

Afin de préciser cette question, je vais l'illustrer avec le détail d'un projet sur lequel je travaille pour mon école.

Ce projet concerne la création d'une application de réservation de place de cinéma.

Il est question pour un utilisateur de pouvoir réserver une place de cinéma pour une certaine séance, qui sera déterminée pour un film donné, dans une salle à une certaine date et un certain horaire.

Ces séance auront été programmées à l'avance par un gérant de cinéma.

Afin de stocker les différentes informations (film, séance, réservation) je dois utiliser une base de donnée MySQL.

J'utilise le formalisme UML afin représenter mes objets dans l'application
.
À partir de mon schéma UML j'en déduis mon schéma de base de données.

Le souci que j'ai actuellement est celui de la représentation d'une séance en base de données.

Actuellement une séance est identifiée de manière unique par la salle dans laquelle elle a lieu, sa date, ainsi que son horaire de début (son horaire de fin étant calculé à partir de la durée du film)
Les horaires sont en fait des tranches de 30 minutes numérotées de 1 à 48, cela permet la création d'un planning simplifié pour le gérant qui choisit sur quels chéneaux il place ses films.

Ces trois informations constituent donc la clé primaire composée de la relation Séance.

Ainsi un tuple Séance peut être représenté de la manière suivante :

Séance ( idSalle, date, horaireDebut, horaireFin, film)

Deux séances peuvent donc se dérouler à la même date pour une même salle mais pas au même horaire)
Si mes souvenirs sont bons, il me semble qu'une clé primaire ne peut être composée que de clé étrangère.

Ce qui signifie qu'il me faut créé une relation Date contenant les différentes date des séances, chacune d'elle identifiées de manière unique (à l'aide d'un idDate).

De même qu'une relation Horaire dans laquelle je listerai tous mes horaires que j'identifierai également de manière unique (à l'aide d'un idHoraire).

Et c'est là que le bât blesse.

En effet mes l'attribut horaireDebut qui compose la clé primaire de la relation Séance n'a que 48 valeurs possibles, je trouve dommage de créer une relation uniquement pour cela.
De même pour les dates même si leur nombres peut être très grand dois-je forcement passer par la création d'une relation Date ?

Ne puis-je pas plutôt composer la clé primaire de la relation Séance à partir de l'id d'une salle, d'une date et d'un horaire sans que ces deux derniers soit eux-mêmes des clés étrangères.

Lors de l'ajout d'une séance j'irais alors vérifier à l'aide d'une contrainte d'intégrité qu'aucune séance pour cette salle n'est la même date ET le même horaire de début. (J’occulte ici les vérifications à effectuer concernant le chevauchement des séances)

Qu'en pensez-vous ?

[escartefigue]

Je n'oserai paraphraser l'excellent article de Fsmrel, article que vous trouverez ici
http://merise.developpez.com/actu/87...TE-par-fsmrel/
Je pense que tout y est

[SQLpro]

D'un point de vue pratique mais aussi pour les performances, il vaudrait mieux que votre séance doit modélisée de la sorte :
TABLE SEANCE : colonne --> (clef--> (IdSalle, DATHEURE_debut), IdFilm)
En effet, et comme vous le précisez, la DATEHEURE de fin est calculée par rapport à DATEHEURE_debut + durée, ces données étant connues
Or un principe fondamentale dans les SGBDR => pas de redondance, même calculée !
Une vue complémentaire sera là pour vous apporter le confort nécessaire à l'implémentation des applicatifs

Et donc de créer une entité planning comportant toutes les combinaisons de DATEHEURE_debut depuis l'an 2016 jusqu'à la fin des temps...

Le fait de créer des entités de type DATE ou DATETIME est classique et impératif. Il vous permettra de simplifier bien des requêtes.
Un exemple ;
Trouver les créneaux vacants entre telle et telle date pour un festival.
Si vous n'avez pas la liste des créneaux disponible, alors une telle requête est extrêmement complex eà établir...

Ce genre de cas est systématique si vous devez par exemple planifier des RB chez le médecin

A +

[StringBuilder]

Bonjour,

Pour répondre à la question initiale, je dirais qu'il y a deux réponses.

D'après MERISE (du moins, ce que j'en ai retenu), OUI
=> En effet, dans une table fille par exemple, ou une table de correspondance, on n'a généralement pas d'identifiant à proprement parler dans le MCD, car non utile.

Exemple avec 3 tables :
UTILISATEUR (id, nom, prenom)
GROUPE (id, nom)
UTIGRP ( ??? lien multiple entre utilisateur et groupe)

Dans cette table UTIGRP, qui sera une simple relation de type "0,n" dans le MCD, on n'a aucune colonne porteuse de donnée.

On ne retrouve donc que les clés étrangères :
id_utilisateur et id_groupe

Ce couple doit être unique.

Donc est un parfait candidat à une clé primaire.

CEPENDANT, si on va plus loin, on se rend compte que si on veut rajouter une relation de type 1,n sur cette relation (par exemple, des horaire d'accès, etc.) on va se retrouve avec des clés étrangères composites, et une clé primaire qui devient mamouth.
=> Et là, la plupart des SGBD vont commencer à ne pas aimer ça, d'un point de vue performances.

Donc en SQL, une bonne pratique que je met maintenant en place systématiquement, c'est :
- Une clé ID de type entier d'une taille compatible avec le nombre de lignes estimées (tinyint, smallint, int, bigint)
- Une ou plusieur clé alternative (contrainte d'unicité) portant sur les tuples de clés étrangères.

=> L'avantage, c'est que tu as une table fille pour l'affectation des groupes, la clé étrangère n'est plus "id_utilisateur, id_groupe" mais "id_utigrp".

Le second avantage, c'est que aujourd'hui, ce "id_utigrp" ne contient que des couples uniques d'utilisateur/groupe.
Si demain je dois rajouter une propriété à cette table et que j'ai besoin de faire sauter cette unicité (par exemple, des dates d'application), je n'ai pas besoin de changer la clé primaire de la table (et donc je ne modifie pas les relations entre tables). J'ai juste à faire sauter ou modifier la contrainte d'unicté que j'ai mis en place sur le couple (id_utilisateur, id_groupe) pour inclure la date de début d'application par exemple.