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 :

Entités faibles similaires et normalisation


Sujet :

Schéma

  1. #1
    Membre émérite

    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 683
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mars 2005
    Messages : 1 683
    Points : 2 575
    Points
    2 575
    Par défaut Entités faibles similaires et normalisation
    Bonjour à tous,

    aujourd'hui j'ai une question qui m'a semblé simple et sur laquelle je cale lamentablement.

    J'ai 2 entités Film (Titre, date de sortie) et Acteur (Nom, prénom, date naissance). Les films et les acteurs ont des Commentaires (Date, pseudo auteur, commentaire).

    Commentaire est une entité faible dans la mesure où le commentaire d'un film n'existe pas sans son film et même chose pour les commentaires sur les acteurs. Corolaire, un commentaire ne peut pas être rattaché à la fois à un Film et un Acteur.

    Pour passer au modèle logique, j'hésite entre :

    1)
    FILM = {Film_Id, Film_Titre, Film_DateSortie}
    ACTEUR = {Acteur_Id, Acteur_Nom, Acteur_Prenom, Acteur_DateNaissance}
    COMMENTAIRE = {Comm_Id, Comm_Date, Comm_Pseudo, Comm_Commentaire}
    FILM_COMMENTAIRE = {#Film_Id, #Comm_Id}
    ACTEUR_COMMENTAIRE = {#Acteur_Id, #Comm_Id}

    (avec une exclusivité de Comm_Id dans les tables FILM_COMMENTAIRE et ACTEUR_COMMENTAIRE)

    ou
    2)
    FILM = {Film_Id, Film_Titre, Film_DateSortie}
    ACTEUR = {Acteur_Id, Acteur_Nom, Acteur_Prenom, Acteur_DateNaissance}
    FILM_COMMENTAIRE = {#Film_Id, FilmComm_Id, Comm_Date, Comm_Pseudo, Comm_Commentaire}
    ACTEUR_COMMENTAIRE = {#Acteur_Id, ActeurComm_Id, Comm_Date, Comm_Pseudo, Comm_Commentaire}

    La première solution me gêne dans la mesure où le modèle ne signifie par l'exclusivité d'un commentaire à un film ou un acteur par lui même.

    La deuxième solution me gêne dans la mesure où on répète la structure d'un commentaire dans chaque entité faible.

  2. #2
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 121
    Points : 4 595
    Points
    4 595
    Par défaut
    Bonjour Vmolines,

    La première solution est la meilleure !... si, à l'avenir, tu dois ajouter des attributs à l'entité "Commentaire", ils seront ajoutés pour toutes les entités qui pointent sur elle.

    Citation Envoyé par Vmolines
    le modèle ne signifie par l'exclusivité d'un commentaire à un film ou un acteur par lui même.
    ==> il s'agit de la contrainte XT dans Merise. Concrètement, il faudra un trigger qui contrôlera qu'un commentaire appartient, obligatoirement, à un film ou à un acteur, mais pas aux deux. Astuce : une vue ou une requête liant FILM_COMMENTAIRE et ACTEUR_COMMENTAIRE via Comm_Id doit être toujours vide...
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  3. #3
    Membre émérite

    Profil pro
    Inscrit en
    mars 2005
    Messages
    1 683
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : mars 2005
    Messages : 1 683
    Points : 2 575
    Points
    2 575
    Par défaut
    Mon premier réflexe aurait été celui là. La répétition étant souvent synonyme de problème de normalisation.

    Cependant, bien qu'ayant les mêmes attributs, un commentaire de film et d'acteur doivent ils être dans la même table ?

    Ce qui me ferait pencher pour des tables distinctes :
    - Un commentaire n'a pas de sens en tant que tel mais uniquement rattaché à l'une ou l'autre des entités. Bizarre de ne pas l'identifier relativement.
    - D'un point de vue optimisation, les commentaires rattachés à une entité seront toujours chargés par rapport à celle ci et rangés physiquement comme ça avec cette solution. Je pourrais avoir une recherche directe d'index sur la table commentaire dédiée. Avec la solution 1, j'aurai une recherche d'index sur la table d'association + une boucle de key lookup sur la table commentaire.

    Au final si la structure de mon commentaire évolue la solution 1 m'économise juste de mettre à jour les 2 tables. En contre partie, ça me semble pas plus juste, moins performant et rafistolé à coup de trigger pour maintenir la cohérence.

  4. #4
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 121
    Points : 4 595
    Points
    4 595
    Par défaut
    Citation Envoyé par Vmolines
    Cependant, bien qu'ayant les mêmes attributs, un commentaire de film et d'acteur doivent ils être dans la même table ?
    ==> ça se discute... mais, je pense que oui.

    Conceptuellement, un commentaire est un texte rattaché à... ce que l'on veut. Les entités concernées peuvent évoluer et les attributs des commentaires aussi.

    Admettons que, à l'avenir, tu veuilles stocker des commentaires liés aux réalisateurs, aux scénaristes, aux directeurs de la photographie, etc... Conceptuellement, il n'y a pas autant d'entité "Commentaire" que d'objets en possédant. Et, dans la pratique (MLD), il faudra que tu aies autant de tables que de liaisons... ce qui me parait gênant.

    Le conceptuel doit primer et, du conceptuel, doit découler les objets de travail (les tables).
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  5. #5
    Membre chevronné
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    août 2007
    Messages
    797
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : août 2007
    Messages : 797
    Points : 2 057
    Points
    2 057
    Par défaut
    Bonjour vmolines et Richard,

    Désolé de ne pas être d'accord avec vous mais il me semble que la solution 1 ne peut pas convenir. Elle signifierait qu'un même commentaire peut s'appliquer à plusieurs films :

    [ FILM ]--0,n----( FILM_COMMENTAIRE )----0,n--[ COMMENTAIRE ]

    Il en va de même pour les acteurs.

    La solution 2 est meilleure de ce point de vue mais induit une entité commentaire par entité de gestion comme vous l'avez souligné l'un et l'autre.

    Il me semble qu'une 3e solution serait plus adéquate :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
      [ FILM ]--0,n----( )----0,1-+
                        |         |
                        x  [ COMMENTAIRE ]
                        |         |
    [ ACTEUR ]--0,n----( )----0,1-+
    Le "x" est une contrainte d'exclusivité signifiant qu'un commentaire ne s'applique qu'à un film ou à un acteur.

    Les cardinalités 0,1 infèrent des tables de liaison au niveau relationnel identifiées par le commentaire et comportant une clé étrangère vers l'entité de gestion :

    Commentaire_Film(Comm_Id, Film_Id)
    Commentaire_Acteur(Comm_Id, Acteur_Id)

    Qu'en pensez-vous ?
    N'oubliez pas de consulter les Cours Merise et la F.A.Q. Merise
    _______________________________________________________

    Les Règles du Club Developpez.com
    Vous avez votre réponse ? Merci de cliquer sur

  6. #6
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    16 678
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 16 678
    Points : 33 723
    Points
    33 723
    Billets dans le blog
    14
    Par défaut
    La meilleure solution est effectivement celle de JPhi33.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  7. #7
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 121
    Points : 4 595
    Points
    4 595
    Par défaut
    Bonjour JPhi33, CinePhil et Vmolines,

    De l'inconvénient de traiter la structure des tables avant le modèle conceptuel...

    Citation Envoyé par JPhi33
    Désolé de ne pas être d'accord avec vous mais il me semble que ni la solution 1 ne peut pas convenir. Elle signifierait qu'un même commentaire peut s'appliquer à plusieurs films
    ==> cette remarque est traitée par :
    Citation Envoyé par Vmolines
    (avec une exclusivité de Comm_Id dans les tables FILM_COMMENTAIRE et ACTEUR_COMMENTAIRE)
    ==> qui signifie, si j'ai ben compris, la création d'un index unique sur #Comm_Id.

    FILM= {Film_Id, Film_Titre, Film_DateSortie}
    ACTEUR= {Acteur_Id, Acteur_Nom, Acteur_Prenom, Acteur_DateNaissance}
    COMMENTAIRE= {Comm_Id, Comm_Date, Comm_Pseudo, Comm_Commentaire}
    FILM_COMMENTAIRE= {#Film_Id, #Comm_Id} ==> index unique sur #Comm_Id
    ACTEUR_COMMENTAIRE= {#Acteur_Id, #Comm_Id} ==> index unique sur #Comm_Id

    Je reste persuadé que la solution 1 est la meilleure car, conceptuellement, un commentaire est, simplement, un objet texte rattaché à... ce que l'on veut. C'est une entité à part entière. Les entités liées aux commentaires peuvent évoluer et les attributs des commentaires aussi. Dans la solution 2, si les attributs des commentaires évoluent, alors il faudra les intégrer à toutes les tables de liaisons !...

    Admettons que, à l'avenir, il failles stocker des commentaires liés aux réalisateurs, aux scénaristes, aux directeurs de la photographie, etc... Conceptuellement, il n'y a pas autant d'entité "Commentaire" que d'objets en possédant. Et, dans la pratique (MLD), il faudra créer autant de tables que de liaisons... ce qui me parait gênant.

    Mais bon, comme habituellement, la balle est dans le camp de Vmolines.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  8. #8
    Membre chevronné
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    août 2007
    Messages
    797
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : août 2007
    Messages : 797
    Points : 2 057
    Points
    2 057
    Par défaut
    Bonjour à tous,

    Citation Envoyé par Richard_35 Voir le message
    De l'inconvénient de traiter la structure des tables avant le modèle conceptuel...
    Je suis bien d'accord avec Richard.



    Citation Envoyé par Richard_35 Voir le message
    Citation Envoyé par JPhi33
    Désolé de ne pas être d'accord avec vous mais il me semble que ni la solution 1 ne peut pas convenir. Elle signifierait qu'un même commentaire peut s'appliquer à plusieurs films
    ==> cette remarque est traitée par :
    Citation Envoyé par Vmolines
    (avec une exclusivité de Comm_Id dans les tables FILM_COMMENTAIRE et ACTEUR_COMMENTAIRE)
    ==> qui signifie, si j'ai ben compris, la création d'un index unique sur #Comm_Id.
    C'est l'interprétation de Richard pour cette contrainte. Je la comprends différemment : pour moi, elle signifie "un commentaire donné ne peut pas être à la fois un commentaire de film et un commentaire d'acteur". A vmolines de nous éclairer sur ce point.

    Mais, soit. Partons de l'hypothèse retenue par Richard : un index unique sur #Comm_Id. On se restreint aux films, le raisonnement pouvant être appliqué aux acteurs par similitude.

    Citation Envoyé par Richard_35 Voir le message

    FILM_COMMENTAIRE= {#Film_Id, #Comm_Id} ==> index unique sur #Comm_Id
    Dans cette hypothèse, une ligne de la table FILM_COMMENTAIRE ne peut référencer qu'une ligne de la table COMMENTAIRE (normal). Mais, puisqu'il y a un index UNIQUE sur #Comm_Id dans la table FILM_COMMENTAIRE, une ligne de la table COMMENTAIRE ne peut référencer qu'une ligne de la table FILM_COMMENTAIRE. Par rétro-ingénierie, en supposant pour l'instant que ces deux tables soient issues d'entités, on obtient le MCD :

    [ FILM_COMMENTAIRE ]--1,1----( )----1,1--[ COMMENTAIRE ]


    Concernant #Film_Id, une ligne de la table FILM_COMMENTAIRE ne peut référencer qu'une ligne de la table FILM. En revanche, une ligne de la table FILM peut référencer plusieurs lignes de la table FILM_COMMENTAIRE (pas d'index UNIQUE cette fois). Par rétro-ingénierie, on obtient le MCD :

    [ FILM ]--0,n----( )----1,1--[ FILM_COMMENTAIRE ]


    Le MCD global est donc :

    [ FILM ]--0,n----( )----1,1--[ FILM_COMMENTAIRE ]--1,1----( )----1,1--[ COMMENTAIRE ]


    La table FILM_COMMENTAIRE n'a pas de clé propre, seulement des clés étrangères. Par conséquent cette table doit être issue d'une association. On aurait donc le MCD suivant :

    [ FILM ]--0,n----( FILM_COMMENTAIRE )----1,1--[ COMMENTAIRE ]

    qui se traduit au niveau relationnel par une clé étrangère dans la table COMMENTAIRE... et l'inexistence d'une table FILM_COMMENTAIRE. C'est bien d'ailleurs la signification conceptuelle de l'index UNIQUE sur #Comm_Id dans FILM_COMMENTAIRE : un commentaire ne peut se rapporter qu'à un seul film.


    En ajoutant la partie acteurs par similitude, on obtient au final ce MCD :

    [ FILM ]--0,n----( FILM_COMMENTAIRE )----1,1--[ COMMENTAIRE ]--1,1----( ACTEUR_COMMENTAIRE )----0,n--[ ACTEUR ]

    (l'association ACTEUR_COMMENTAIRE ne se dérive pas en table mais en clé étrangère dans la table COMMENTAIRE)


    C'est là que vmolines doit nous éclairer sur le sens de l'exclusivité : un commentaire donné doit-il s'appliquer à la fois à un film et à un acteur ? Si c'est oui, on en reste là. Si c'est non, alors le MCD qui en découle est celui de mon précédent post.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
      [ FILM ]--0,n----( )----0,1-+
                        |         |
                        x  [ COMMENTAIRE ]
                        |         |
    [ ACTEUR ]--0,n----( )----0,1-+
    Avec des cardinalités 0,1 il n'y a plus, cette fois, de clés étrangères dans la table COMMENTAIRE mais des tables de lien (les tables disparues réapparaissent) :

    FILM_COMMENTAIRE(#Film_Id, #Comm_Id)
    ACTEUR_COMMENTAIRE(#Acteur_Id, #Comm_Id)

    A noter que la clé de ces tables est #Comm_Id. #Film_Id et #Acteur_Id sont des clés étrangères non identifiantes... ce qui suffit à garantir l'unicité de #Comm_Id. Quelle coïncidence !
    A noter aussi que ce modèle permet de lier COMMENTAIRE à d'autres entités (réalisateur, scénariste, etc.)
    N'oubliez pas de consulter les Cours Merise et la F.A.Q. Merise
    _______________________________________________________

    Les Règles du Club Developpez.com
    Vous avez votre réponse ? Merci de cliquer sur

  9. #9
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 121
    Points : 4 595
    Points
    4 595
    Par défaut
    Bonjour à tous,

    FILM_COMMENTAIRE= {#Film_Id, #Comm_Id} ==> index unique sur #Comm_Id

    Citation Envoyé par JPhi33
    Dans cette hypothèse, une ligne de la table FILM_COMMENTAIRE ne peut référencer qu'une ligne de la table COMMENTAIRE (normal).
    ==> vrai.


    Citation Envoyé par JPhi33
    Mais, puisqu'il y a un index UNIQUE sur #Comm_Id dans la table FILM_COMMENTAIRE, une ligne de la table COMMENTAIRE ne peut référencer qu'une ligne de la table FILM_COMMENTAIRE.
    ==> vrai. Peut, car il y a aussi la table ACTEUR_COMMENTAIRE.


    Citation Envoyé par JPhi33
    Par rétro-ingénierie, en supposant pour l'instant que ces deux tables soient issues d'entités, on obtient le MCD :
    [ FILM_COMMENTAIRE ]--1,1----( )----1,1--[ COMMENTAIRE ]
    ==> non. Peut=0,1, donc : [ FILM_COMMENTAIRE ]--1,1----( )----0,1--[ COMMENTAIRE ]


    En final, je pense que nous sommes tous les trois d'accord (JPhi33, CinePhil et moi-même). D'ailleurs, en reprenant l'ordre logique des choses :

    Règles de gestion :
    • 1 film peut posséder 0 ou n commentaires ;
    • 1 commentaire peut concerner 0 ou 1 seul film ;
    • 1 acteur peut posséder 0 ou n commentaires ;
    • 1 commentaire peut concerner 0 ou 1 seul acteur ;
    • 1 même commentaire ne peut pas concerner 1 film et 1 acteur à la fois.


    MCD (c'est celui que tu proposais, JPhi33...) :

    Nom : Capture.JPG
Affichages : 106
Taille : 32,4 Ko

    Tables :
    Film(IdFilm, …)
    Acteur(IdActeur, …)
    Commentaire(IdCommentaire, Pseudo, …)
    Film_Commentaire(#IdFilm, #IdCommentaire, …) ==> index unique sur #IdCommentaire
    Acteur_Commentaire(#IdActeur, #IdCommentaire, …) ==> index unique sur #IdCommentaire
    Contrainte XT (trigger) ==> une vue liant Film_Commentaire à Acteur_Commentaire via #IdCommentaire ne doit renvoyer aucun élément.

    Plus ou moins vite fait...
    Qu'en pensez-vous ?
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  10. #10
    Membre chevronné
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    août 2007
    Messages
    797
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 59
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Chef de projet en SSII

    Informations forums :
    Inscription : août 2007
    Messages : 797
    Points : 2 057
    Points
    2 057
    Par défaut
    Bonjour,

    Citation Envoyé par Richard_35 Voir le message
    Film_Commentaire(#IdFilm, #IdCommentaire, …) ==> index unique sur #IdCommentaire
    Acteur_Commentaire(#IdActeur, #IdCommentaire, …) ==> index unique sur #IdCommentaire
    Pas d'accord en ce qui concerne la clé de ces tables et la contrainte d'unicité sur #IdCommentaire.
    Je maintiens (voir mon précédent post) qu'une association 0,1 - 0,n (ou 1,n) se dérive en une table dont la clé est celle de la table côté 0,1 (ici #IdCommentaire) et comporte une clé étrangère qui référence la table côté 0,n.

    Donc :

    Film_Commentaire(#IdCommentaire, #IdFilm, …) ==> L'index unique sur #IdCommentaire est inutile : #IdCommentaire étant la clé primaire de cette table, l'unicité est garantie.
    Acteur_Commentaire(#IdCommentaire, #IdActeur, …) ==> Idem
    N'oubliez pas de consulter les Cours Merise et la F.A.Q. Merise
    _______________________________________________________

    Les Règles du Club Developpez.com
    Vous avez votre réponse ? Merci de cliquer sur

  11. #11
    Expert confirmé Avatar de Richard_35
    Homme Profil pro
    Inscrit en
    juillet 2007
    Messages
    3 121
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 121
    Points : 4 595
    Points
    4 595
    Par défaut
    Bonjour,

    Tu as raison, JPhi33, ta solution économise un index.
    Dis-nous et à bientôt,
    Richard.
    ----------------------------------------------------------------------------------------------
    En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur .
    et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !

  12. #12
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 963
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 20 963
    Points : 49 770
    Points
    49 770
    Billets dans le blog
    1
    Par défaut
    Une solution plus simple serait de faire un héritage exclusif, en considérant une entité générique "mère" que l'on pourrait appelé objet_médiatique qui aurait un id et un commentaire nullable. Dès lors film et acteur serait des spécialisations de l'objet médiatique.... avec tous les avantages de la clef unique propagée (rangement des tuples si table IOT/clustered).

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Access et entités faibles et spécifiques ?
    Par maph1 dans le forum Modélisation
    Réponses: 6
    Dernier message: 20/02/2008, 19h33
  2. PB! entité faible sous MySQL
    Par Bugger24 dans le forum Requêtes
    Réponses: 0
    Dernier message: 10/10/2007, 21h50
  3. entité faible en sql
    Par MeKesTudi dans le forum Langage SQL
    Réponses: 3
    Dernier message: 07/12/2005, 18h23
  4. Générer un identifiant relatif > l'entité faible en prati
    Par vmolines dans le forum Décisions SGBD
    Réponses: 1
    Dernier message: 19/08/2005, 16h59
  5. ENTITE FAIBLE
    Par Whismeril dans le forum Langage SQL
    Réponses: 2
    Dernier message: 20/01/2005, 23h53

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