Discussion :

[msarra]

Bonjour tous le monde,

Dans le cadre d'un stage ,je dois créer une base de donnée qui regroupe tous les fichiers des services de l'entreprise ( des données qui sont liée entre eux )

Je suis dans l'étape de conception et de la modélisation de cette base , je vous donne un exemple pour pouvoir expliquer mon problème.

j'ai une table client qui contient un numéro et un autre numéro d'immatriculation ( qui peut exister ou pas !!!!) j'ai un attribut plateforme ou chaque client est affecté à cette dernière, en effet j'ai quatre type de plateforme donc pour mon client X je dois récuperer les infos dans l'une des tables plateforme ,comment je pourrai modélisé ce cas qui represente Le OU exclusif , le cas ou le client peut se trouvé dans une et une seule plateforme au lieu de chercher dans toute les plateformes .

Merci d'avance

[Donpi]

Je suis pas certain d'avoir compris...

Mais une table client, une table immatriculation et une table plateforme, c'est des relations classiques.

[msarra]

Je suis pas certain d'avoir compris...

Mais une table client, une table immatriculation et une table plateforme, c'est des relations classiques.

Voilà ,j'ai dans la table client des caractéristiques qui ne puissent être pertinentes que pour certaines occurrences d'une des quatre entités , forcément ma table client doit être lié au quatre table mais pour chaque occurence y'as une liaison avec une et une seule table ...
Certes , c'est un peu compliqué bien au niveau applicatif .

[aieeeuuuuu]

Bonjour,

Difficile en effet de bien comprendre avec un tel niveau d'abstraction.
Avec des exemples plus concrets, tout serait plus clair.
Je pense que vous devriez vous tourner vers l'héritage.

[msarra]

Bonjour,

Difficile en effet de bien comprendre avec un tel niveau d'abstraction.
Avec des exemples plus concrets, tout serait plus clair.
Je pense que vous devriez vous tourner vers l'héritage.

Je vous donne un exemple :

[msarra]

Bonjour,

Difficile en effet de bien comprendre avec un tel niveau d'abstraction.
Avec des exemples plus concrets, tout serait plus clair.
Je pense que vous devriez vous tourner vers l'héritage.

j'ai pensée à mettre un id_plateforme inclus entre [1,4] ou bien quatre attribut pour chaque id_plateforme (idplateforme1,2 ...)
Et lors de l'insertion au niveau des tables ,je vais chercher pour chaque id la plateforme correspondante et faire le traitement nécessaire.
Donc au niveau conceptuel j'aurai une association avec les quatre tables .

[fsmrel]

Bonsoir,

'ai une table client qui contient un numéro et un autre numéro d'immatriculation ( qui peut exister ou pas !!!!)

Ce qui laisse à penser qu’il y a comme une typologie des clients. Pourriez-vous expliquer pourquoi le numéro d’immatriculation est facultatif ?

ma table client doit être lié au quatre table mais pour chaque occurrence y'as une liaison avec une et une seule table ...

Ce qui voudrait dire qu’un client est rattaché à au moins et au plus une plate-forme.

S’il en est ainsi, la représentation du MCD peut commencer en prenant cette forme :





L’entité-type PLATEFORME permet de modéliser la partie structurelle commune aux 4 plates-formes (dont le nombre pourra du reste varier dans le temps, mieux vaut prévoir).

Une plate-forme est identifiée par la valeur que prend l’attribut PlateformeId. Le mickey « <pi> » symbolise le fait que PlateformeId est identifiant principal (ou primaire, primary identifier). Dans la mesure où deux plates-formes ne peuvent pas avoir le même numéro de téléphone, l’attribut NumeroTel est identifiant alternatif de l’entité-type PLATEFORME (<ai> est synonyme de alternate identifier). Même chose concernant l’attribut NumeroBoitier. Si ce que j’ai écrit n’est pas conforme à la réalité, faites-le savoir.

ClientNumero et l’identifiant naturel de l’entité-type CLIENT, c'est-à-dire celui qui est connu de l’utilisateur. ClientId est un identifiant artificiel. Cet identifiant donnera lieu au niveau SQL à une clé primaire, dont on a tout intérêt à ce qu’elle soit invariante. Voyez ce qu’a écrit l’excellent Yves Tabourier à ce sujet (Cf. « De l’invariance des clés primaires »).

Maintenant, si des plates-formes ont des spécificités, à savoir des attributs particuliers, on pourra les spécialiser (même chose pour les clients).

[msarra]

Bonsoir,


Ce qui laisse à penser qu’il y a comme une typologie des clients. Pourriez-vous expliquer pourquoi le numéro d’immatriculation est facultatif ?




Ce qui voudrait dire qu’un client est rattaché à au moins et au plus une plate-forme.

S’il en est ainsi, la représentation du MCD peut commencer en prenant cette forme :





L’entité-type PLATEFORME permet de modéliser la partie structurelle commune aux 4 plates-formes (dont le nombre pourra du reste varier dans le temps, mieux vaut prévoir).

Une plate-forme est identifiée par la valeur que prend l’attribut PlateformeId. Le mickey « <pi> » symbolise le fait que PlateformeId est identifiant principal (ou primaire, primary identifier). Dans la mesure où deux plates-formes ne peuvent pas avoir le même numéro de téléphone, l’attribut NumeroTel est identifiant alternatif de l’entité-type PLATEFORME (<ai> est synonyme de alternate identifier). Même chose concernant l’attribut NumeroBoitier. Si ce que j’ai écrit n’est pas conforme à la réalité, faites-le savoir.

ClientNumero et l’identifiant naturel de l’entité-type CLIENT, c'est-à-dire celui qui est connu de l’utilisateur. ClientId est un identifiant artificiel. Cet identifiant donnera lieu au niveau SQL à une clé primaire, dont on a tout intérêt à ce qu’elle soit invariante. Voyez ce qu’a écrit l’excellent Yves Tabourier à ce sujet (Cf. « De l’invariance des clés primaires »).

Maintenant, si des plates-formes ont des spécificités, à savoir des attributs particuliers, on pourra les spécialiser (même chose pour les clients).

Merci pour votre réponse fsmrel ,j'ai penséé à faire l'héritage ou j'ai une table mére plateforme et quatre table fille (types) .

Qu'est ce que vous en pensez ?

[fsmrel]

Bonsoir msarra,

j'ai pensé à faire l'héritage ou j'ai une table mère plateforme et quatre table fille (types).

Vous confondez « être » et « avoir »...

Pour prendre un exemple classique, celui des personnes, on va dire qu’on peut par exemple voir les choses ainsi :

Une entreprise a des employés ;

Une entreprise est une personne ;

Un employé d’une entreprise est aussi une personne.

L’entreprise et l’employé ont des propriétés communes telles que le nom, l’adresse, le numéro de téléphone.

Elles ont par ailleurs des propriétés qui leur sont propres :

Un employé a un matricule, un numéro de sécurité sociale, occupe une fonction, etc., toutes choses qui ne caractérisent pas une entreprise.

Une entreprise a un forme juridique, un numéro SIREN, etc., toutes choses qui ne caractérisent pas un employé.

Dans le diagramme ci-dessous, l’entité-type PERSONNE est ce qu’on appelle un surtype par rapport aux sous-types que sont ENTREPRISE et EMPLOYE :





Et dans la série « avoir », une entreprise peut employer (avoir) des employés. Une entreprise emploie au moins un employé et au plus plusieurs ; un salarié est employé par au moins et au plus une entreprise :





Si donc vous voulez spécialiser des plates-formes, c’est que certaines d’entre elles ont des caractéristiques, des propriétés que n’ont pas les autres. Qu’en est-il ?