Discussion :

[merise_lover]

Bonjour a tous,

Je suis actuellement en stage de deuxieme année informatique et je suis en charge d'un projet qui necessite une part d'analyse.

Le contexte :
Lorsqu'un étudiant a un probleme informatique, il appel le service technique de l'université afin de le lui exposer. Actuellement la personne essaye de le résoudre tel quel, oralement.

Le but du projet est donc de développer une application permettant à la personne du service technique d'enregistrer les informations concernant l'appel : les coordonnées du concerné, le problème exposé, ainsi que la priorité de l'appel (basse, haute, critique) et son statut (ouvert, en attente, résolu). Les appel pouront ensuite être consultés et leur statut modifiés.

En fait on m'a donné un document contenant la description des besoins ainsi que l'entête des tables à implémenter. A partir de là j'ai donc traduit bêtement les tables en MCD mais celui-ci n'est pas normalisé. Je l'ai donc modifié et normalisé en 3FN.

Voici donc les 2 MCD, pouvez vous me dire si le second est correcte ?

Il ne comporte pas de TA car toutes les relations sont de type 1 à plusieurs

j'aurrais surement d'autres questions par la suite.

Merci pour votre aide.


Premiere version du MCD

En fait dans la table Calls, tous les champs user_* correspondaient en fait au champs customer_* de la table Customer_Details, c'est une des raisons pour laquelle la relation Calls n'était pas normalisée !


Version normalisé en 3 FN du MCD

[fsmrel]

Bonjour,

Version normalisé en 3 FN du MCD

Hum...
Il est préférable de ne pas être trop affirmatif quand on n’avance pas les preuves (intégrale des DF et couverture minimale). Considérons la table Customer_Details. Si par exemple il existe une dépendance fonctionnelle customer_telephone → customer_location, et si customer_telephone n’entre pas dans la composition d’une clé candidate, alors la 3 FN n’est pas respectée.

Votre représentation graphique n’est pas un MCD, car sont absentes les associations entre entités-types (et manque donc la formalisation des liens d’intégrité référentielle au niveau MLD).

Qui plus est, cette représentation est plutôt de niveau MLD, car des attributs comme customer_UUN figurent deux fois.

Pour rester au niveau MLD, vous avez retenu {customer_UUN} comme clé de la table Customer_Details : je ne sais pas ce qu’est un UUN, mais je supposerai qu’il s’agit d’une information dont vous n’avez pas la maitrise totale. S'il en est ainsi, mieux vaut ravaler l'UUN au rang de clé alternative (unicité garantie) et mettre en oeuvre une clé primaire du type {customer_id} où customer_id est un attribut dont vous avez la maitrise totale et dont l’invariance puisse être ainsi garantie. A supposer que l’on soit obligé de remplacer une valeur d’UUN (comme ça arrive par exemple pour les numéros de SIREN des entreprises, lorsque l'INSEE envoie ses correctifs), selon votre représentation, toutes les tables où figure cet UUN doivent être mises à jour (Customer_Details et Calls dans votre exemple).

[merise_lover]

Bonjour,
Considérons la table Customer_Details. Si par exemple il existe une dépendance fonctionnelle customer_telephone → customer_location, et si customer_telephone n’entre pas dans la composition d’une clé candidate, alors la 3 FN n’est pas respectée.

Non j'ai bien vérifié, il n'existe pas dans le second MCD d'attribut non primaire dépendant d'autres attributs non primaires

Votre représentation graphique n’est pas un MCD, car sont absentes les associations entre entités-types (et manque donc la formalisation des liens d’intégrité référentielle au niveau MLD).

Comme je l'ai dit toutes les relations sont de types 1 a plusieurs il n'y as donc pas de Type d'association si c'est ce dont vous parlez. Est il impossible d'avoir un schéma sans TA ?

Qui plus est, cette représentation est plutôt de niveau MLD, car des attributs comme customer_UUN figurent deux fois.

Oui ce sont des clés étrangères.

Pour rester au niveau MLD, vous avez retenu {customer_UUN} comme clé de la table Customer_Details : je ne sais pas ce qu’est un UUN, mais je supposerai qu’il s’agit d’une information dont vous n’avez pas la maitrise totale.

le "Customer" est un étudiant, son UUN est son "Universal User Name" (numero étudiant ) il est unique et ne change jamais.

[fsmrel]

j'ai bien vérifié, il n'existe pas dans le second MCD d'attribut non primaire dépendant d'autres attributs non primaires

Scripta manent, verba volant. Les règles de gestion des données doivent être rédigées et justifiées. Notamment celle qui stipule qu’à un n° de téléphone peuvent correspondre plusieurs "locations". A défaut, il ne faut pas affirmer que la base de données est en 3e FN.

Est il impossible d'avoir un schéma sans TA ?

C'est effectivement impossible, parce que vous cherchez à représenter un modèle formalisé, selon des règles établies, et non pas une simple esquisse informelle. A défaut, le lecteur ne peut pas avoir que de vagues idées sur ce que vous cherchez à représenter et y consacre inutilement du temps. La sémantique doit être exprimée notamment par les associations (nommées) entre entités.

ce sont des clés étrangères

Alors exprimez les liens.

le "Customer" est un étudiant, son UUN est son "Universal User Name" (numero étudiant ) il est unique et ne change jamais.

Tout comme le N° de SIREN des entreprises ? Qui détermine cet UUN ? L’application ? Votre entreprise ? Un système externe ?

[merise_lover]

Ok je crois que je vais reprendre depuis le début car je me suis un peu emmelé les pinceaux. en fait j'ai confondu MCD et bdd. En effet lorsqu'il existe des cardinalités x,1, le TA concerné ne doit pas être traduit en table, il faut juste placer l'identifiant du TE opposé dans le TE possedant les cardinalités x,1. C'est en fait ce que j'ai fait ici et mais celà n'a aucun sens puisque il n'apparait plus aucun TA.

Pauvre de moi, je ne suis qu'un petit débutant.

Allé, au travail!!

[fsmrel]

Bonjour merise_lover,


Bon courage à vous. N'hésitez pas à soumettre votre "V2", en commençant par le commencement, c'est-à-dire un MCD bien parlant, vous avez tous les ingrédients pour cela.

fsmrel

[merise_lover]

Bonjour à tous,

Vendredi j'ai eu un entretien avec la personne responsable de l'équipe qui utilisera l'application. On a donc défini les besoins exactes et quelques (et non des moindres) modifications ont été apportées par rapport à la "v1". Ainsi, voici la liste des attributs, les dépendances fonctionnelles, les régles de gestion ainsi que le mcd V2 (avec des zoulis TA cette fois-ci ).

Listes des propriétés

Customer_UUN
Customer_forename
Customer_surename
Customer_telephone
Customer_email
Customer_role

School_id
School_desc

Call_id
Call_date
Call_details
Call_resolution
Call_date_updated
Call_date_closed
Quick_call
#record_lock (j'en parlerai plus tard)

Person_id
Person_forename
Person_surename

Priority_id
Priority_desc

Status_id
Status_desc

Tag_id
Tag_desc

Category_id
Category_desc

Hardware_id
Hardware_desc

Browser_id
Browser_desc

Dépendances fonctionnelles

Customer_UUN => Customer_forename, Customer Surename,
Customer_telephone, Customer_email, Customer_role

School_id => School_desc

Call_id => Call_date, Call_details, Call_resolution,
Call_date_updated, Call_date_closed, Quick_call, #record_lock

Person_id => Person_forename, Person_surename

Priority_id => Priority_desc

Status_id => Status_desc

Tag_id => Tag_desc

Category_id => Category_desc

Hardware_id => Hardware_desc

Browser_id => Browser_desc


Rêgles de gestion

Le numero UUN est le numéro permettant d’identifier le client au sein de l’université. C’est un code à 7 chiffres pour les étudiants, de type 0701349, et un code alpha numerique de 8 caractères maximum pour les membre du personel de type nomprénomNo . Etant unique et ne variant pas dans le temps il peut donc etre utilisé comme identifiant de l’ entité customer_details.

Un client n’appartient qu’à une et une seul école (1,1), il peut être soit « student », soit « staff » soit « applicant » soit « enquirer » soit « other » (rôle)

Le Call_id est généré auutomaitquement par le système

Un appel concerne : un et un seul client (1,1)
un et un seul technicien (1,1)
une et une seule priorité (1,1)
un et un seul statut (1,1)
un et un seul type de machine (1,1)
un et un seul navigateur internet (1,1)
une et une seule catégorie (1,1)
au minimum 1 tag (l’application permettra de n’en saisir que 5
maximum. (1,N)

Quick_call est un booléen signifiant que l’appel a été résolu immediatement (problème de login etc.) les propriétés call_details, call_resolution et call_update sont alors vides ; les propriétés call_date et call_date_close sont identiques.

Un tag s’il existe, est forcement associé à un appel au minimum (1, N )

MCD V2



Questions

1) Bon tout d'abord qu'en pensez vous ?

2) Le booléen Quick_call est il une bonne solution. Dois-je procéder autrement ?

3) Parlons en de ce record_lock ! C'est en fait un booléen permettant de savoir si la table est actuellement en mise à jour. Si c'est le cas, une modification de celle-ci est donc imppossible.

Perso je trouve ça lourd comme manière de procéder, aurriez-vous fait la même chose ?

En fait, la personne qui avait conçu les tables au départ avait mis tous les attributs relatifs à un appel dans la table Call, maintenant que celà a été modifié ce n'est plus la table call qui sera en mis à jour lors de la mis à jour d'un appel mais toutes les tables qui en dépendent. Et je ne crois pas que ça soit une bonne solution de créer un attribut record_lock dans chaque table.

En cours on nous a (vaguement) parlé des transactions ainsi que des verrous mais je n'ai pas vmt tout compris serait-ce une solution de substitution adéquat ?

[hed62]

2) Le booléen Quick_call est il une bonne solution. Dois-je procéder autrement ?

C'est comme cela que cela sera géré au niveau du MLD. Niveau MCD, il faut modéliser un héritage. Les appels sont sousclassés selon qu'ils sont résolus immédiatemetn ou non.

3) Parlons en de ce record_lock ! C'est en fait un booléen permettant de savoir si la table est actuellement en mise à jour. Si c'est le cas, une modification de celle-ci est donc imppossible.

Ce genre de choses sont purement techniques, et ne doivent pas apparaitre. De plus les système de lock sont gérés par les SGBD.

En cours on nous a (vaguement) parlé des transactions ainsi que des verrous mais je n'ai pas vmt tout compris

Ceci explique cela... Ce n'est pas une substition, mais LA solution à employer.

[merise_lover]

Merci hed62 pour ces précisions,

n'ayant pas beaucoup d'expérience en héritage (et surtout dans la manière de le transformer en bdd) j'ai réalisé 2 schéma.

Qu'en pensez vous ?
Les 2 solutions sont bonnes une seule ? Aucune ?





Comment ensuite les lier au reste du schéma ?




Merci.

[hed62]

Au niveau MCD, inutile de préfixer tous les attributs afin de rendre chaque nom unique, c'est une étape pour le MLD(MPD?).

n'ayant pas beaucoup d'expérience en héritage

Au niveau MCD, c'est la même chose qu'au niveau d'un diagramme de classes (j'espère que cela t'aide )

Les 2 solutions sont bonnes une seule ? Aucune ?

Intuitivement je choisirai la première (ne serait-ce que pour des soucis d'évolutivités : si plus tard un Quick_call possède un attribut comme le temsp nécessaire à répondre, on trouvera de suite l'endroit où le ranger).
Maintenant, des experts diront peut être que la 2e est équivalente

Comment ensuite les lier au reste du schéma ?

Ce qui est spécfique au quick_call est relié au quick_call
Ce qui est spécfique au complete_call est relié au complete_call
Ce qui est commun au deux est relié au call

[merise_lover]

Au niveau MCD, inutile de préfixer tous les attributs afin de rendre chaque nom unique, c'est une étape pour le MLD(MPD?).

c.a.d ? l'ai je fait ?

Au niveau MCD, c'est la même chose qu'au niveau d'un diagramme de classes (j'espère que cela t'aide )

Oui je vois ce que vous voulez dire. En revanche J'ai quelque peu oublié certaines rêgles de passage MCD => BDD, je suppose que c'est le rôle du LMD ? (

Intuitivement je choisirai la première (ne serait-ce que pour des soucis d'évolutivités : si plus tard un Quick_call possède un attribut comme le temsp nécessaire à répondre, on trouvera de suite l'endroit où le ranger).
Maintenant, des experts diront peut être que la 2e est équivalente


Ce qui est spécfique au quick_call est relié au quick_call
Ce qui est spécfique au complete_call est relié au complete_call
Ce qui est commun au deux est relié au call

Ok je continue alors !

[hed62]

c.a.d ? l'ai je fait ?

call_id, call_date, call_date_closed => id, date, date_closed

je suppose que c'est le rôle du LMD

MLD, MPD, oui.

[merise_lover]

ok voici la V3...




Qu'en pensez vous !

Je viens de voir un truc qui m'avait échappé concernant le rôle du "customer", dois-je le modéliser par un attribut comme je l'ai fait (il y'aurra 5 rôles) ou suis-je obligé de créer un TE rôle ?

C'est bon ? Ai fini ? peux passer au MLD ?

[merise_lover]

call_id, call_date, call_date_closed => id, date, date_closed


MLD, MPD, oui.

Ok merci pour le tuyau, bon maintenant c'est fait c'est fait

[hed62]

ou suis-je obligé de créer un TE rôle ?

On n'est jamais obligé de rien, mais bon, comme les roles font partie du référentiel et qu'ils risquent peu de changer... Oui je créerai une entité role.

Quelle est cette façon de nommer les relations: get_priority, get_... On dirai une dérive vers un diagramme de classe...

[merise_lover]

On n'est jamais obligé de rien, mais bon, comme les roles font partie du référentiel et qu'ils risquent peu de changer... Oui je créerai une entité role.

Ok je vais revoir mon schéma alors. V4 me voilà !

Quelle est cette façon de nommer les relations: get_priority, get_... On dirai une dérive vers un diagramme de classe...

Oui je n'avais pas d'autre idée en fait. Des suggestions ?

[merise_lover]

V4...


Un client peut posséder plusieurs rôles suivant son évolution au sein de l’université. (1,N)

Un rôle peut ne pas concerner encore d’étudiant (création de l’application) (0,N)

Serait-ce à peu près correct maintenant ?

Merci.

[hed62]

L'important dans la question est : peut il avoir plusieurs roles, a la fois ? Si non, la cardinalité max est de 1

[merise_lover]

L'important dans la question est : peut il avoir plusieurs roles, a la fois ? Si non, la cardinalité max est de 1

En fait je ne suis pas trop sûr ! Un "customer" peut être candidat et appeler le service client puis devenir étudiant à l'université et rappeller ce même service auquel cas on lui attribuera un rôle différent.
Celà ne signifie pas qu'il peut avoir plusieurs rôles en même temps, simplement c'est une manière de garder une trace des rôles qu'il a eu.
Est-ce donc correct ?

[hed62]

Je vais poser la question autrement : a une date donnée, un customer a combien de role au maximum ?