IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Quand une propriété devient-elle objet ?


Sujet :

Schéma

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    334
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 334
    Par défaut Quand une propriété devient-elle objet ?
    Bonjour,

    J'aurais une question d'ordre extrêmement général: j'appréhende la méthode Merise afin de créer une base de données. Je suis en train de créer un dictionnaire d'objets et je me rend compte qu'il y a peu d'objets naturels qui s'en détachent.

    Par exemple j'ai une liste de produits référencés comme suit :

    1.1.1
    1.1.2
    1.2.1
    2.1.1

    Où le premier chiffre est le code produit et les 2 autres un incrément (ce qui est humainement très compréhensible) de sous-produit et de sous-sous-produit style 1.1.1 = produit 1 sous-produit 1 sous sous produit 1. De plus le produit 1 peut se retrouver avec un sous produit et sous sous produit identique pour une autre condition genre :

    Site production 1 : 1.1.1
    Site production 2: 1.1.1
    Dans l'absolu les sous et sous sous produits des 2 sites n'ont rien en commun mais c'est la notation en place...

    Je me heurte à un problème qui est :

    Dois-je créer une table :

    Element
    idElement
    code produit
    code sous produit
    code sous sous produit

    ou 3 tables :
    produit sous-produit et sous sous produit

    Bref, je suis en peu perdu et je voudrais savoir comment savoir si une propriété mérite d'être extraite d'une table pour constituer un objet à part entière. De plus un code étant déjà en place, je me demande si je considère qu'un 'sous produit 1' est en relation 1,n avec produit puisque 'sous produit 1' va forcément se retrouver sur tous les produits (et à ce moment 1 sera PK) ou si je mets un identifiant unique PK et '1' serait en quelque sorte le nom du sous produit.

    En vous remerciant,

    C. Tobini

  2. #2
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 218
    Billets dans le blog
    16
    Par défaut
    Bonjour C. Tobini,

    Cela fait à peu près deux mois que nous avons discuté des concepts entité-relation et relationnels, notamment des entités faibles, des clés primaires et alternatives.

    Et voilà maintenant que les utilisateurs vous font des misères :

    Site production 1 : 1.1.1
    Site production 2: 1.1.1
    Dans l'absolu les sous et sous sous produits des 2 sites n'ont rien en commun mais c'est la notation en place...
    J’ai oublié à l’époque de vous préciser qu’au niveau relationnel, l’utilisateur ne doit avoir aucun pouvoir de décision quant aux valeurs prises par les clés primaires. Ça n’est pas une loi, mais un bon moyen de ne pas faire de cauchemars.

    Supposons donc qu’un produit ait pour valeur de clé primaire <1>, que l’un de ses sous-produits ait pour valeur de clé primaire <1,1> et que l’un des sous-sous-produits ait pour valeur de clé primaire <1,1,1>.
    Supposons encore que le même produit ait un autre sous-produit de clé primaire <1,2> et un sous-sous-produit de clé primaire <1,2,1>.

    Comme l’utilisateur veut gérer son propre système de codification, vous définissez une clé alternative à cet effet (que vous pouvez qualifier informellement de "clé utilisateur" dans les discussions). Et comme chaque site de production veut voir la valeur 1.1.1 quand nous avons de notre côté <1,1,1> et <1,2,1>, pour dédoublonner, vous faites participer la clé primaire du site de production à la clé alternative (qui sera donc simultanément clé étrangère par en relation avec la table des sites), laquelle est le point d’entrée dans le système pour l’utilisateur, mais en aucun cas celui-ci n’aura accès à la clé primaire.

    Concernant les produits, les sous-produits, etc., l’identifiant au niveau Merise correspond évidemment à votre clé primaire.

    Au niveau SQL, pour faire prendre en compte les clés alternatives, vous utilisez la clause UNIQUE de l’instruction Create Table.

    Evitez les cauchemars...

  3. #3
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    334
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 334
    Par défaut
    Bonjour fsmrel et merci encore de votre intervention,

    J'ai relu les articles en question du forum et je lis sur le net des articles relatifs à la construction d'une base de données, j'avoue qu'il est plus que temps d'investir dans un ouvrage de qualité (vous en citez 2 que je vais me procurer).

    Mon problème réside dans le fait que j'assimile des notions que j'avais survolées en formation universitaire et je tente d'appréhender la démarche complète de création des entités-types (dépendances fonctionnelles, élimination de la redondance...) ce qui n'est pas simple en raboutant les données de cours du net qui quelquefois se contredisent...

    Merci pour les infos concernant ce post, je vois désormais une piste :-)

    J'aurais 2 petites questions supplémentaires, j'ai eu des exemples sur le net des axiomes d'Armstrong mais ce n'est pas clair, je voudrais m'appuyer sur un exemple que vous avez donné dans un précédent post :

    Tout d'abords (un partie de) la théorie que j'ai trouvé sur le net:

    augmentation : si X -> Y, alors XZ -> Y pour tout groupe Z d'attributs appartenant au schéma de relation.

    J'avoue ne pas saisir la notion de Z appartenant au schéma relation, la participation de Z à cette relation et son intégration à X. Il y a également sur le net une variante si X -> Y, alors XZ -> YZ

    décomposition : si X -> Y et Z contenu dans Y, alors X -> Z.

    Idem pour Z contenu dans Y.

    Vous donnez un exemple sur un cas concret :

    DF1 : {Course, Jockey} -> Cheval
    DF2 : {Course, Jockey} -> Dossard
    DF3 : {Course, Cheval} -> Jockey
    DF4 : {Course, Cheval} -> Dossard
    DF5 : {Course, Dossard} -> Jockey
    DF6 : {Course, Dossard} -> Cheval

    déduction selon les axiomes d'Armstrong :

    DF7 : {Jockey, Cheval, Course} -> Dossard ____ (axiome d’augmentation et règle de décomposition)
    DF8 : {Course, Dossard, Cheval} -> Jockey ____ (idem)
    Etc.

    Etant un peu perdu dans ces notions pourriez vous svp me guider sur l'application des axiomes pour cet exemple ?

    Une petite question également sur les couvertures minimales, j'ai cet exemple d'un cours PDF:



    Autant je comprends la décomposition, autant je ne saisis pas comment procéder à l'élimination et le remplacement en question pourriez vous me guider également vers la méthode à appliquer (pas forcément la réponse mais la démarche).

    En vous remerciant,

    C. Tobini

  4. #4
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 218
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

    Citation Envoyé par ctobini
    il est plus que temps d'investir dans un ouvrage de qualité (vous en citez 2 que je vais me procurer).
    Quels sont-ils, que je confirme ?

    Citation Envoyé par ctobini
    je tente d'appréhender la démarche complète de création des entités-types (dépendances fonctionnelles, élimination de la redondance...) ce qui n'est pas simple en raboutant les données de cours du net qui quelquefois se contredisent...
    En gros, il y a deux approches : une approche descendante et une approche ascendante.
    La première fait plutôt appel à la perception que l’on du cas à modéliser, et repose pas mal sur l’intuition, sans trop chercher à dépiauter finement l’information (on aboutit à un dossier de conception générale, avec un MCD lisible par tous, montrant les choses à haute altitude). Au fur et à mesure que l’on sent que l’on est sur la bonne voie, on approfondit, pour aboutir à une conception beaucoup plus détaillée.
    La seconde approche consiste plutôt à mettre à plat l’information, en l’atomisant au maximum (attributs) au sein d’une immense relation dite universelle, abordée selon une approche anatomique, mécanique, qu’il faut normaliser (4e forme normale au minimum) à partir des contraintes traduites en dépendances fonctionnelles (traduction en fait des règles de gestion des données), pour produire les entités-types... Cette seconde approche requiert une excellente connaissance de la théorie relationnelle et des techniques associées (utilisation des axiomes d’Armstrong, détermination de la couverture minimale, des clés candidates, vérification de la 5e forme normale etc.), toutes choses nécessitant du temps, une rigueur extrême, une grande habitude et... beaucoup d’aspirine). Elle est beaucoup moins pratiquée, car difficile, longue et source de grosses migraines (voyez l’exercice amorcé avec le document PDF évoqué ci-dessous, et qui ne donne lieu au final qu’à un modèle plutôt riquiqui...)
    Le mieux est de panacher : approche descendante, vérification de la normalisation (BCNF) pour éliminer les redondances, etc., révision avec les utilisateurs des modèles échafaudés pour s’assurer qu’on ne fait pas fausse route. La technique du yoyo en quelque sorte, mais mettant en jeu des ensembles de taille raisonnable. A noter que l’approche descendante, menée sérieusement, élimine pratiquement tous les cas de viols potentiels de 4e et 5e formes normales (aux innocents les mains pleines !)

    L’exercice est difficile, et l’on ne peut être vraiment rassuré que lorsque le projet concerné est en production et fonctionne (ce qui au demeurant n’est pas si facile à prouver...)


    Citation Envoyé par ctobini
    augmentation : si X -> Y, alors XZ -> Y
    Ceci n’est pas précisément l’axiome d’augmentation, lequel est le suivant :

    Soient X, Y et Z des sous-ensembles dont les éléments sont des attributs d’une relation R.
    Si X-> Y alors XZ -> YZ
    XZ représente ici l’union (au sens de la théorie des ensembles) de X et Z (X U Z). Même principe pour YZ.
    Par exemple, si A, B, C, D, E, F, G, H, I, J sont des attributs de R, avec :
    X = {A, B, C}
    Y = {D, E, F, G}
    Z = {H, I, J}
    On peut lire les choses ainsi :
    Si {A, B, C} -> {D, E, F, G}
    Alors {A, B, C, H, I, J} -> {D, E, F, G, H, I, J}
    Attention, Z n’est pas intégré à X, en fait on procède à l’union de X et Z. Même chose dans le cas de Y.

    Le prétendu axiome d’augmentation : si X -> Y, alors XZ -> Y n’est qu’une règle inférée de cet axiome et de la règle de décomposition :
    Si X -> Y alors XZ -> YZ ____ (augmentation)
    Si XZ -> YZ alors XZ -> Y ___ (décomposition)


    Citation Envoyé par ctobini
    pourriez vous svp me guider sur l'application des axiomes pour cet exemple ?
    Cas de DF7 :

    Je rappelle la règle d’Union, inférée des axiomes d’Armstrong, selon laquelle :
    si X -> Y et X-> Z alors X -> YZ. (J’avais probablement oublié de mentionner cette règle).

    On part de DF3 et DF4
    DF3 : {Course, Cheval} -> {Jockey}
    DF4 : {Course, Cheval} -> {Dossard}
    (Les dépendants, c’est-à-dire les attributs situés à droite étant singletons, je ne les ai pas mis entre crochets, mais par précaution, je le fais ici.)

    Par application de la règle d’Union :
    {Course, Cheval} -> {Jockey, Dossard}
    Puis, par augmentation :
    {Course, Cheval, Jockey} -> {Jockey, Dossard}
    Et par décomposition :
    {Course, Cheval, Jockey} -> {Dossard}


    Concernant l’exemple du cours (fichier PDF) :

    La couverture minimale (je préfère irréductible, qualificatif plus approprié) doit être débarrassée de la DF
    CE -> A
    car on sait la produire à partir de C -> A (donné) à qui l'on fait subir une augmentation puis une décomposition :
    1)____CE -> AE (augmentation)
    2)____CE -> A (décomposition)
    Pour montrer que CG -> B peut être inférée des autres DF, on peut utiliser une autre règle inférée des axiomes, celle de Composition, selon laquelle :
    Si X -> Y et Z -> T alors XZ -> YT.
    Ainsi, par union de CG -> D et C -> A, on obtient :
    CG -> AD
    puis par augmentation (par C) :
    CG -> ACD
    et par transitivité (puisque ACD -> B est donnée) :
    CG -> B
    Etc.

  5. #5
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    334
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 334
    Par défaut
    Bonjour,

    Merci de votre réponse, j'avoue ne pas avoir le temps dans l'immédiat de lire la totalité de votre réponse, je le ferai d'ici ce week-end. Pour info, les 2 ouvrages en question sont :

    'The Relational Database Dictionary' (chez O'Reilly) et 'Introduction aux Bases de Données' (Chris Date) en version française donc

    Merci effectivement de me confirmer ceci, car je pense passer commande ce week-end, dans la mesure où le second ouvrage a environ 8 jours de délai de livraison. Le premier est dispo en version PDF en revanche, pratique.

    Merci et à bientôt,

    C. Tobini

  6. #6
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 218
    Billets dans le blog
    16
    Par défaut
    Bonjour,

    Les ouvrages sont les bons.
    Concernant 'The Relational Database Dictionary' le bouquin tient dans la poche (18x10,5 cm) ce qui est pratique quand on prend les transports en commun.
    Pour l'autre ouvrage, je ne l'ai qu'en version anglaise. Quoi qu'il en soit, faites attention à commander la dernière édition (la 8e).

    Bonne lecture et bon week-end.

  7. #7
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 218
    Billets dans le blog
    16
    Par défaut
    Bonsoir,

    Je vous soumets une solution.

    Je rappelle le principe que je propose, car à mon sens fondamental concernant les clés primaires :

    Les utilisateurs n’ont pas accès à ces clés. En tout cas, ils ont interdiction d’en fournir les valeurs et de remplacer celles-ci : il en va de la stabilité de la base de données, de la performance des requêtes et des traitements. A la limite, on peut les autoriser à voir ces clés primaires, dans la mesure où elles sont lisibles.

    En contrepartie, ces utilisateurs sont habilités à définir leurs propres clés, lesquelles sont qualifiées d’alternatives. Ces clés sont pour eux des points d’entrée dans le système et ils en déterminent les valeurs comme bon leur semble : en l’occurrence, appellera une telle clé : clé utilisateur. Ceci se veut l’écho de ce que vous écrivez :
    Site production 1 : 1.1.1
    Site production 2: 1.1.1
    Dans l'absolu les sous et sous sous produits des 2 sites n'ont rien en commun mais c'est la notation en place...
    C’est-à-dire que si les produits ne sont pas spécifiques aux sites (ils le seraient que l’approche serait la même, toutes choses égales par ailleurs), les sous-produits le sont. Du point de vue de la modélisation, cela revient à dire qu’il doit y avoir une relation entre le sous-produit et le site. Du même coup, le sous-sous-produit hérite de cette relation.

    De manière pragmatique, une clé utilisateur peut être composée d’éléments appartenant à l’utilisateur, modifiables par lui, et d’éléments complémentaires inaltérables, permettant au besoin de dédoublonner les jumeaux parfaits.

    Par exemple, un site a pour clé primaire {Id_Site} et pour clé alternative {User_Site}. Le système attribue les valeurs pour {Id_Site}. L’utilisateur habilité attribue les valeurs {User_Site} pour les différents sites (1 ou "S1", etc.) Cette clé alternative n’est évidemment à mettre en œuvre que si fonctionnellement le besoin s’en fait sentir.

    De la même façon, un produit a pour clé primaire {Id_Produit} et le système en attribue les valeurs. L’utilisateur habilité définit les valeurs {User_Produit} pour les différents produits, comme il l’entend. Il est vrai que depuis toujours, les utilisateurs aiment bien maîtriser les valeurs des "codes-produits", "codes-sous-produits", etc.

    Un sous-produit a pour clé primaire {Id_Produit, Id_Site, Id_Sous_Produit} et le système attribue les valeurs de Id_Sous_Produit, relativement à {Id_Produit, Id_Site}. L’utilisateur habilité définit les valeurs {User_Sous_Produit} pour les différents sous-produits, comme il l’entend.

    La clé utilisateur (alternative, rappelons-le) est composée du couple {User_Sous_Produit, Id_Site} : Deux utilisateurs de sites différents peuvent donc fournir la même valeur pour des sous-produits différents, pas de problème, l’attribut Id_Site permet de garantir l’unicité des valeurs de la clé utilisateur. Rappelons que l’utilisateur d’un site donné n’a besoin de manipuler que le seul attribut User_Sous_Produit, l’attribut Id_Site lui est indifférent (contrairement à ce qui se passe pour le système).

    Un sous-sous-produit a pour clé primaire {Id_Produit, Id_Site, Id_Sous_Produit, Id_Sous_Sous_Produit} et le système attribue les valeurs de Id_Sous_Sous_Produit relativement à (Id_Produit, Id_Site, Id_Sous_Produit). L’utilisateur habilité définit les valeurs {User_Sous_Sous_Produit} pour les différents sous-sous-produits. Une fois de plus, la présence de l’attribut Id_Site permet de résoudre les problèmes de gémellité de sous-sous-produits entre sites :

    La clé utilisateur est composée du couple {User_Sous_Sous_Produit, Id_Site} : Deux utilisateurs de sites différents peuvent donc fournir la même valeur pour des sous-sous-produits différents, pas de problème, l’attribut Id_Site permet de garantir l’unicité des valeurs de la clé utilisateur. Rappelons que l’utilisateur d’un site donné n’a besoin de manipuler que le seul attribut User_Sous_Produit, l’attribut Id_Site lui est indifférent (comme dans le cas du sous produit).

    Le MLD ci-dessous résume graphiquement la situation. Comme DB Designer ne semble pas connaître le concept de clé alternative, j’ai ajouté à la main la clause UNIQUE pour les clés utilisateurs (Instructions Create Table à la suite du graphique).




    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    -------------------------------------------
    -- Base de données Produits (SQL Server) --
    -------------------------------------------
    
    CREATE TABLE Site (
      Id_Site INTEGER NOT NULL,
      Nom_Site CHAR(48) NOT NULL,
      User_Site CHAR(16) NOT NULL,
      PRIMARY KEY(Id_Site),
      UNIQUE(User_Site)
    );
    
    CREATE TABLE Utilisateur (
      Id_User INTEGER NOT NULL,
      Id_Site INTEGER NOT NULL,
      Nom_User CHAR(48) NOT NULL,
      PRIMARY KEY(Id_User),
      FOREIGN KEY(Id_Site)
        REFERENCES Site(Id_Site)
          ON DELETE NO ACTION
    );
    CREATE TABLE Produit (
      Id_Produit INTEGER NOT NULL,
      Nom_Produit CHAR(48) NOT NULL,
      User_Produit CHAR(16) NOT NULL,
      PRIMARY KEY(Id_Produit),
      UNIQUE(User_Produit) 
    );
    
    CREATE TABLE Sous_Produit (
      Id_Produit INTEGER NOT NULL,
      Id_Site INTEGER NOT NULL,
      Id_Sous_Produit INTEGER NOT NULL,
      Nom_Sous_Produit CHAR(48) NOT NULL,
      User_Sous_Produit CHAR(16) NOT NULL,
      PRIMARY KEY(Id_Produit, Id_Site, Id_Sous_Produit),
      UNIQUE(User_Sous_Produit, Id_Site), 
      FOREIGN KEY(Id_Produit)
        REFERENCES Produit(Id_Produit)
          ON DELETE CASCADE
          ON UPDATE NO ACTION,
      FOREIGN KEY(Id_Site)
        REFERENCES Site(Id_Site)
          ON DELETE NO ACTION
    );
    
    CREATE TABLE Sous_Sous_Produit (
      Id_Produit INTEGER NOT NULL,
      Id_Site INTEGER NOT NULL,
      Id_Sous_Produit INTEGER NOT NULL,
      Id_Sous_Sous_Produit INTEGER NOT NULL,
      Nom_Sous_Sous_Produit CHAR(48) NOT NULL,
      User_Sous_Sous_Produit CHAR(16) NOT NULL,
      PRIMARY KEY(Id_Produit, Id_Site, Id_Sous_Produit, Id_Sous_Sous_Produit),
      UNIQUE(User_Sous_Sous_Produit, Id_Site), 
      FOREIGN KEY(Id_Produit, Id_Site, Id_Sous_Produit)
        REFERENCES Sous_Produit(Id_Produit, Id_Site, Id_Sous_Produit)
          ON DELETE CASCADE
    );
    Requêtes

    La contrepartie avec ce système est que lorsqu’un utilisateur accède par le biais de ses propres clés à un sous-produit ou à un sous-sous-produit, (ou le crée, le modifie, ou le supprime) on doit toujours fournir dans les requêtes la valeur du site Id_Site associé au sous-produit (normalement, un utilisateur est attaché à un site). Sinon, gare à la casse ! Mais c'est le prix à payer, si pour deux sites on peut avoir même User_Sous_Produit ou même User_Sous_Sous_Produit...

    Observations

    La modélisation que je vous ai proposée permet de garantir que pour un site donné, on ne pourra pas avoir deux sous-produits ayant même valeur (User_Sous_Produit), même chose pour les sous-sous-produits. Si vous estimez que la propagation de l’attribut Id_Site engendre un système trop sophistiqué, vous pouvez vous en dispenser, mais dans ces conditions vous ne pourrez plus contrôler la présence de sous-sous-produits doublons, sinon par la mise en œuvre de mécanismes du genre triggers ou procédures stockées. A vous de réfléchir.

  8. #8
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 218
    Billets dans le blog
    16
    Par défaut
    Pour information, j’ai écrit :

    Citation Envoyé par fsmrel
    Si vous estimez que la propagation de l’attribut Id_Site engendre un système trop sophistiqué, vous pouvez vous en dispenser, mais dans ces conditions vous ne pourrez plus contrôler la présence de sous-sous-produits doublons, sinon par la mise en œuvre de mécanismes du genre triggers ou procédures stockées.
    Le Standard SQL permet de définir des contraintes. Ainsi, au cas où vous ne propageriez pas l'attribut Id_Site dans Sous_Sous_Produit, pour interdire les doublons des codes de l‘utilisateur concernant les sous-sous-produits, vous disposez à cet effet de l’instruction Create Assertion. Exemple (non testé) :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    
    Create Assertion  Assert_SSP Check
      (Not exists (
                   Select   SP.Id_Site, SSP.User_Sous_Sous_Produit
                   From     Sous_Produit As SP, Sous_Sous_Produit As SSP
                   Where    SP.Id_Produit= SSP.Id_Produit
                     And    SP.Id_Sous_Produit= SSP.Id_Sous_Produit
                   Group by Id_Site, User_Sous_Sous_Produit
                   Having Count (*) > 1
                  )  
       ) ;
    
     -- Ou encore
                   
    Create Assertion Assert_SSP Check
      (Unique (
               Select   SP.Id_Site, SSP.User_Sous_Sous_Produit
               From     Sous_Produit As SP, Sous_Sous_Produit As SSP
               Where    SP.Id_Produit= SSP.Id_Produit
                 And    SP.Id_Sous_Produit= SSP.Id_Sous_Produit
              ) 
      ) ;
    Mais à ce jour, les SGBD ne proposent pas cette instruction. Dommage...

  9. #9
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    334
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 334
    Par défaut
    Bonjour et désolé de ma réponse un peu tardive,

    Merci beaucoup pour cet exemple très détaillé, c'est agréable pour la compréhension !

    J'aurais besoin que vous validiez quelques petits points de ce que je pense avoir compris d'un point de vue fonctionnel de votre schéma :

    Pour rappel :



    - les PK comme Id_site son donc gérés par le système et s'auto-incrémentent

    - tel que je le vois, User_site est optionnel et sert à distinguer diverses implications sur un même site (ex: Nom_cite est une ville et User_site est le secteur de rattachement d'un utilisateur si plusieurs secteurs).

    - Dans mon exemple de Produit 18.1.2 si ce produit est 'Carte mère' par exemple, 'Carte mère' sera Nom_Produit de la table Produit et '18' sera User_Produit (et ainsi de suite pour Sous- et Sous-sous-Produit).

    De cette manière si 'Carte mère' et '18' appartient déjà au schéma, le Produit '18' sera unique et chaque utilisateur en fonction du site impliqué pourra décliner '18' en Sous- et Sous-sous-Produit en liant par clés alternatives les 3 tables.

    Est-ce correct ?

    J'ai effectivement jeté un oeil sur les assertions, c'est dommage que ça ne soit pas implémenté...

    En vous remerciant,

    C. Tobini

  10. #10
    Expert éminent
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 218
    Billets dans le blog
    16
    Par défaut
    Bonsoir C. Tobini,


    Vous écrivez :
    les PK comme Id_site son donc gérés par le système et s'auto-incrémentent
    Les PK comme Id_Site sont effectivement gérées par le système, mais au sens large (vous faites partie du système) : elles peuvent être auto-incrémentées, mais si cela ne vous convient pas, vous pouvez affecter les valeurs vous-même, par requête ou par programme. Vous pouvez utiliser des timestamps, des entiers, par incrément, ou pourquoi pas par hachage si la situation l’exige (contentions), tous les coups sont permis. La règle de base est qu’une valeur de clé primaire ne change pas, d’où la nécessité que l’utilisateur n’ait aucun pouvoir pour changer la valeur d’une telle clé.


    tel que je le vois, User_site est optionnel et sert à distinguer diverses implications sur un même site (ex: Nom_cite est une ville et User_site est le secteur de rattachement d'un utilisateur si plusieurs secteurs).
    Je n’ai pas tout compris et j’ai un point d’interrogation au-dessus de la tête... Un utilisateur peut-il être en relation avec plusieurs sites ? Si oui, il faut le modéliser. Merci d’illustrer votre propos par l’exemple.


    De cette manière si 'Carte mère' et '18' appartient déjà au schéma, le Produit '18' sera unique et chaque utilisateur en fonction du site impliqué pourra décliner '18' en Sous- et Sous-sous-Produit en liant par clés alternatives les 3 tables.
    Là aussi, pourriez-vous donner un exemple complet d’affectation des valeurs par les utilisateurs, concernant les sous-produits et les sous-sous-produits ?

    Quant à lier les 3 tables par clés alternatives (AK), je rappelle que les seuls liens prévus sont de type PK-FK, sinon, si vous mettez les AK dans le coup, vous redonnez à l’utilisateur la possibilité de modifier les liens, ce qui viole la règle de base évoquée ci-dessus...

    Que l’utilisateur modifie les valeurs des AK, c’est son droit, elles lui appartiennent, mais pas les liens d’intégrité définis par vous-même.

    Bon courage pour cette reprise,

    Fsmrel

  11. #11
    Membre éclairé
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    334
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 334
    Par défaut
    Bonjour,

    Je vais donner un exemple concret, en faisant table rase de mon exemple précédent, j'ai apparement mal compris certaines choses

    Prenons l'exemple d'un produit 16.18.36, produit n°16, son Sous-Produit 18 et Sous-Sous-Produit 36.

    Voici la représentation instinctive :



    Le produit 16 est commun à tous les sites (bien que certains sites puissent ne pas le 'traiter' et donc ne pas avoir de Sous et Sous-sous-Produits associés). Les Sous et Sous-sous-Produits sont uniques pour un site, un Utilisateur peut donc saisir Sous-Produit 18 et Sous-sous-produit 36 ainsi que les noms associés.

    Les points que je ne saisi pas sont les suivants :

    - La notion de 'point d'entrée' pour les clés utilisateurs comme User_Site. D'un point de vue fonctionnel, si un utilisateur est rattaché à un seul site, à quoi sert d'attribuer un User_Site unique ? Par ailleur si l'utilisateur peut modifier son User_Site et si un Id_Site identifie un site et est PK si je prends cet exemple :



    L'utilisateur Alpha étant également sur Site_France (Id_Site 54) veut saisir son User_Site, la PK est rompue en cas de tentative d'ajout. A moins que :



    Pour un site donné, le fait d'avoir plusieurs User_Site necéssite d'avoir plusieurs tables (mais ça m'étonnerais, je pense que j'interpréte mal...).

    - Les utilisateurs ne pouvant agir sur les clés primaires, selon votre exemple les PK Produits, Sous-Produit et Sous-sous-Produit doivent-ils à ce moment être fixés par le système et l'exemple 16.18.36 sont alors saisis par l'utilisateur en tant que clé utilisateur ?

    Par exemple :



    A ce moment le système gère les clés (ce qui est plus fiable) et les clés utilisateurs permettent de maintenir l'unicité entre Produit, Sous-Produit, Sous-sous-Produit et Site, reflétant la réalité.

    En vous remerciant,

    C. Tobini

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 3
    Dernier message: 18/06/2009, 15h59
  2. Accèder à une propriété d'un objet
    Par piotrr dans le forum C#
    Réponses: 2
    Dernier message: 05/06/2009, 16h17
  3. Réponses: 9
    Dernier message: 25/02/2008, 11h40
  4. Personnalisation d'une propriété d'un objet
    Par Domi2 dans le forum VBA Access
    Réponses: 2
    Dernier message: 25/08/2007, 09h42
  5. [POO] Problème lors de l'appel d'une propriété d'un objet.
    Par akecoocoo dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 24/08/2005, 08h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo