Discussion :

[JordanHD]

Bonjour,
Je suis actuellement sur un projet où une base de données est déjà existante j'essaye d'analyser le modèle générer depuis SQL serveur pour voir si des améliorations sont possibles ou bien si toutes les fonctionnalités qui doivent être implantées sont supporté.

Je vous décris rapidement le contexte :
dans les applications cliente des contrôles utilisateur de liste sont utilisés pour afficher des données. Ces contrôles de type liste View (contrôle utilisateur Windows forme) sont paramétrés grâce à des configurations stockées sur la base de données.

Je vous montre le schéma généré.


J'avais quelques questions que je n'arrive pas à résoudre comme on le voit les relations sont doublés d'après ce que j'ai pu en déduire il semblerait que ça soit peut-être pour un gain de performance lors des requêtes.
je voudrais votre avis là-dessus.
À ma connaissance je n'ai jamais vu en conception de BD que doubler des relations pouvaient être utile c'est pour cela que j'ai besoin d'avis extérieur. Ou bien toutes autres remarques concernant le schéma.

Merci

[escartefigue]

bonjour,

Cela dit, "les relations sont doublées" ça implique quoi concrètement en terme de modèle physique ?
Cette représentation graphique n'est elle pas simplement une façon de présenter les contraintes d'intégrité ?
Vous devriez communiquer le DDL de vos tables et index pour vérifier ce point.

[JordanHD]

En terme de modèle physique il y a deux association avec des cardinalité 1.1 et 1.n. Ce qui implique une clé étrangère dans chaque table, alors qu'une devrais suffire à mon avis, sauf qu'ici il y à du coup une redondance chaque table pointe sur l'autre.

je ne sais pas où le trouver le DDL en fait pour pouvoir vous le communiquer. Je n'ai pas non plus de MCD.

[fsmrel]

Bonsoir,


Le diagramme comporte effectivement des cycles a priori pas très sains. Pour qu’on y voie un peu plus clair, pourriez-vous transmettre le script de création des tables ? Pour générer ce script, cliquer droit sur le nom de la base de données et suivre la procédure de génération des scripts :

[JordanHD]

Oui j'avais complètement oublier que l'on pouvais générer un script de cette manière, merci bien.

J'ai donc générer un script uniquement des tables utiles dans le contexte que j'évoque.

Script.sql

Voilà j'espère que ça vous aidera à voir un peu plus clair, car je n'arrive toujours pas à comprendre le pourquoi du comment de ce schéma.

[JordanHD]

J'ai réalise le MCD depuis le schéma que j'ai récupérer pour essayer d'avoir une vue plus claire et donc analyser les modifications qui peuvent être apportés, ou si les fonctionnalités qui doivent être implanter sont supporté et bien sur si les tables sont maintenable pour ajouter des fonctionnalités.

j'ai rédiger les règles de gestion du MCD :
• R1 : Une liste est personnaliser pas 1 et 1 seul environnement
• R2 : Un environnement peut personnaliser une ou plusieurs listes
• R3 : Un environnement est associé à 1 et 1 seul type d’apparence
• R4 : Un type d’apparence est associé à 0 ou plusieurs environnements
• R5 : Un environnement est associé à 1 et 1 seul type de vue
• R6 : Un type de vue est associé à 0 ou plusieurs environnements
• R7 : Un environnement est associé à 1 et 1 seul type de bordure
• R8 : Un type de bordure est à associé à 0 ou plusieurs environnement
• R9 : Une colonne est associée à 1 et seul type d’alignement
• R10 : Un type d’alignement est associé à 0 ou plusieurs colonnes
• R11 : Un environnement possède une ou plusieurs colonnes
• R12 : Une colonne appartient à 1 et 1 seul environnement
• R13 : Un environnement est trié par 1 ou plusieurs attributs
• R14 : Un attribut permet de trier 1 et un seul environnement
• R15 : Une liste est personnalise par 0 ou plusieurs utilisateur
• R16 : Un utilisateur peut personnaliser 0 ou plusieurs liste

Pour la R17 je n'ai pas vraiment réussi à en sortir une phrase du à l'incompréhension du modèle (ne vous fier pas à la relation ternaire sur le MCD)

Comme on le voit dans le premier schéma que j'ai pue vous montrer la table CONF_LISTVIEWS_USER possède le couple (IDUser, IDListView) comme clé primaire mais aussi une clé étrangère pointant sur la table CONF_LISTVIEW_ENV.
La relation n'est donc pas une simple association ternaire avec des cardinalités n n de chaque côtés. Sinon la clé primaire serais un composer des trois entités.

Depuis ce mcd qui est censé représenter les tables à l'heure actuelle j'ai modifier des choses pour en déduire un nouveau MCD



Donc d'après ce dernier MCD j'ai rédiger les nouvelles règles de gestion qui ont été impacter.

• R17 : Un utilisateur et une liste peut être personnaliser par 0 ou plusieurs environnement.
• R19 : Une liste a pour défaut une et une seul liste
• R20 : Une liste est la liste par défaut d’une ou plusieurs listes
• R11 et R12 modification : Un attribut devrait être lié à une colonne ce qui éviterait une redondance de donnée avec le champ CodeAttrOrvar de la table LISTVIEWS_COL
• Solution :
o Supprimer le champ CodeAttrOrVar
o Ajouter dans l’association des relations R11 et R12 les champs de la table LISTVIEWS_SORT
o Supprimer la table LISTVIEWS_SORT en conséquence

J'ai cette fois ci bien déterminer une association ternaire pour R15,R16,R17 car il faut qu'un utilisateur puisse posséder plusieurs environnement pour une même liste.
J'ai ajouter une association réflexive sur l'entité LISTVIEW pour permettre à une liste d'avoir une liste "parente" ou bien d'être parente de plusieurs liste.
J'ai enfin supprimer l'entité LISTVIEW_SORT (qui devrais se nommer LISTVIEW_ATTRIBUT d'ailleurs) et placer dans la relation R11 et R12 les attribut de cette entité en supprimant la redondance de l'attribut "CodeAttrOrVar" de l'entité LISTVIEW_COL

(Cette dernière relation devrais permettre de garder l'attribut d'une colonne pour un environnement tout en conservant dans ce même environnement la fonctionnalité tri d'un environnement) ce n'est peut être pas très claire.

Voilà donc si il y a des choses à dire sur tout ça n’hésite pas.

[fsmrel]

Bonsoir,


Bravo pour avoir dressé l’inventaire des règles de gestion des données, ça n’a pas dû être évident...

Concernant l’association TRIER (règles R13 et R14), il es vrai qu’elle ne convient pas, car l’attribut CodeAttrOrVar de la table CONF_LISTVIEWS_SORT peut prendre une valeur exotique, absente de la table CONF_LISTVIEWS_COL.

Au niveau MCD, l’entité-type CONF_LISTVIEWS_SORT doit être vue comme une spécialisation (sous-type) de l’entité-type CONF_LISTVIEWS_COL (relation d’héritage) :





Faire migrer les attributs IsAsc et Ordre (je ne parle même pas de l’attribut CodeAttrOrVar) dans l’association Appartenir n’est pas une bonne tactique, car pour chaque colonne de chaque table, ces attributs devront être renseignés (ou pire, marqués Null), alors que cela ne concerne qu’un nombre restreint d’attributs par table. A mon sens, l’association Appartenir doit retrouver ses cardinalités d’origine (cf. règles R11 et R12).

A quoi correspond l’attribut IsAttrOrVar de l’entité-type CONF_LISTVIEWS_COL ? Une redondance ?


il faudra qu'on examine plus à fond cette histoire de ternaire, mais pour le moment, la table issue de l’association PERSONNALISE du 2e MCD a les caractéristiques suivantes :

Elle a pour en-tête : {IDListView, IDUser, IDCustom, nom},

Mais, conséquence de la règle R1, il existe la dépendance fonctionnelle {IDListView} -> {IDCustom}, faisant que IDCustom ne peut pas appartenir à la clé de la table, clé qui se réduit donc à la paire {IDListView, IDUser}.

Mais, du fait de la dépendance fonctionnelle, la deuxième forme normale est violée et la table PERSONNALISE doit être décomposée en deux tables d’en-têtes respectifs :

{IDListView, IDCustom} et {IDListView, IDUser},

Autrement dit on boucle, sinon c’est l’association Personnaliser qui saute, c'est-à-dire les règles R1 et R2 et par conséquent la dépendance fonctionnelle {IDListView} -> {IDCustom}...