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 :

Répertoire téléphonique


Sujet :

Schéma

  1. #21
    Membre à l'essai Avatar de debutant001
    Profil pro
    Eric
    Inscrit en
    Mai 2002
    Messages
    47
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Eric

    Informations forums :
    Inscription : Mai 2002
    Messages : 47
    Points : 24
    Points
    24
    Par défaut
    Bonjour fsmrel et encore merci pour ces nouvelles corrections/explications !

    Voici donc une Nième version (je ne sais plus compter jusque là, tellement il y en a eu) du MCD : (et en espérant qu'il n'y ait plus d'erreur d'inattention cette fois ! )

    Nom : Répertoire Téléphonique MCD.jpg
Affichages : 1810
Taille : 92,3 Ko

    J'ai préféré garder l'entité TITRE comme suggéré... (j'ai cru comprendre d'après diverses lectures que le type ENUM n'est vraiment pas du tout apprécié des DBA )

    Et voici le MLD associé : (suivant vos recommandations au niveau clés alternatives)

    Nom : Répertoire Téléphonique MLD.jpg
Affichages : 1707
Taille : 122,1 Ko

    Par contre, il y a quelque chose que je n'arrive pas à comprendre dans les dernières modifications de l'entité SITE et des entités TELEPHONE, MAIL et PSEUDO :

    • Entité SITE : dans les règles de gestion, deux inscrits ne peuvent pas partager la même URL => on a donc ajouté un identifiant alternatif pour régler ce pb, ce qui empêche aussi qu’un inscrit ait plus d’une fois la même URL.
    • Entités TELEPHONE, MAIL et PSEUDO => on a défini des clé alternatives afin d'éviter qu'un inscrit ait deux fois le même numéro de téléphone, mail ou pseudo.

    Pourquoi pour un même traitement (ajout d'un coté d'un identifiant alternatif dans le MCD et de l'autre de clé alternatives dans le MLD, mais en fait c'est la même chose non ?) on obtient pas au niveau du MLD le même résultat ? (ou alors j'ai - encore - fait une erreur quelque part...)
    Ou encore, pourquoi n'avoir pas utilisé la même méthode pour palier à ces deux problèmes ?
    Et enfin, avec ses nouvelles modifs, du coup un inscrit ne peut plus partager le même téléphone ou mail ou pseudo alors ?

    Sinon, voici le MPD que je propose :

    Nom : Répertoire Téléphonique MPD.jpg
Affichages : 1825
Taille : 128,7 Ko

    C'est parce que, au niveau MCD, la cardinalité de l'association entre les entités INSCRIT et TELEPHONE est de type 1,n -1,1 que DB-MAIN symbolise la clé étrangère {InscritId} de la table TELEPHONE par "equ" au lieu du "ref" habituel ?

    Sinon, j'ai regroupé toutes les tables dans un même espace de stockage (REP_TEL_SPACE) mais est-ce judicieux ?

  2. #22
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir Éric,


    Citation Envoyé par debutant001
    ajout d'un coté d'un identifiant alternatif dans le MCD et de l'autre de clé alternatives dans le MLD, mais en fait c'est la même chose non ?
    Bonne remarque : contrairement à d’autres AGL, avec DB-MAIN on peut parfaitement définir certaines clés alternatives au stade du MCD, avant de devoir attendre de passer au MLD, alors que j’ai appliqué mes vieux réflexes PowerAMC etc.

    Exemple avec l’entité-type TELEPHONE :

    On commence par rendre TelephoneNumero identifiant (partiel) :






    Dans un 2e temps on ouvre la fenêtre « property box » qui va bien en cliquant sur « id’: TelephoneNumero », puis en cliquant sur le bouton de la ligne « components », on ouvre la fenêtre « Multiple choice dialog » :




    On fait passer le lien « r:TEL_INS.INSCRIT » devant TelephoneNumero :





    Et l’identifiant relatif est bien là :





    Prenant la forme d’une clé alternative au stade MLD :







    Citation Envoyé par debutant001
    du coup un inscrit ne peut plus partager le même téléphone ou mail ou pseudo alors ?
    Si. La clé alternative ci-dessus étant la paire {InscritId, TelephoneNumero}, on ne plus avoir deux fois la valeur <1, 0123456789>, mais on peut néanmoins avoir les valeurs <1, 0123456789> et <2, 0123456789> puisqu’elles sont différentes.



    Citation Envoyé par debutant001
    C'est parce que, au niveau MCD, la cardinalité de l'association entre les entités INSCRIT et TELEPHONE est de type 1,n -1,1 que DB-MAIN symbolise la clé étrangère {InscritId} de la table TELEPHONE par "equ" au lieu du "ref" habituel ?
    Oui. Disons que ce symbolisme résume la contrainte suivante dans le langage de la théorie relationnelle :

    INSCRIT{InscritId} = TELEPHONE{InscritId}

    En français : à tout moment, la valeur de la projection de la variable INSCRIT sur l’attribut InscritId et la valeur de la projection de la variable TELEPHONE sur l’attribut InscritId doivent être égales.

    Par contre, dans le cas d’une cardinalité 0,N -1,1, la contrainte est du type inclusion :

    INSCRIT{InscritId} ⊇ TELEPHONE{InscritId}



    Citation Envoyé par debutant001
    j'ai regroupé toutes les tables dans un même espace de stockage (REP_TEL_SPACE) mais est-ce judicieux ?
    Ça ne peut pas faire de mal. Pour ma part, je n’utilise pas cette possibilité, car j’ai trop l’habitude de définir l’aspect physique des choses directement dans le code SQL, d’autant plus que les SGBD sont tous très différents à ce stade. Dans cet ordre d’idées, la norme SQL veille à ne pas empiéter sur des terrains qu’elle ne peut qu’ignorer et qui évoluent très sensiblement au fil du temps...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #23
    Membre à l'essai Avatar de debutant001
    Profil pro
    Eric
    Inscrit en
    Mai 2002
    Messages
    47
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Eric

    Informations forums :
    Inscription : Mai 2002
    Messages : 47
    Points : 24
    Points
    24
    Par défaut
    Bonjour fsmrel,

    (de retour après quelques jours de congés bien mérités ! )

    Ok, donc si je comprends bien mon MLD est maintenant correct et mon MPD aussi : c'est top ça !
    Il ne reste donc plus qu'à établir le code SQL correspondant... (Menu Transform/Quick SQL...)

    A ce propos, doit-on normalement définir les "attribus/propriétés" (comme un CHAR(20) ou VARCHAR(30) etc...) des colonnes de chaque table dans le MPD ou lors de la création du code SQL ?
    (je n'ai aucune info à ce propos, mon livre s'arrêtant au MLD seulement et le tuto que je suis passe du MLD au SQL directement.)

  4. #24
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir Éric,


    Citation Envoyé par debutant001
    Il ne reste donc plus qu'à établir le code SQL correspondant... (Menu Transform/Quick SQL...)
    Vous pouvez aussi voir ce que donne la génération en fonction du SGBD (norme incluse) :

    File > Generate :






    Citation Envoyé par debutant001
    Doit-on normalement définir les "attributs/propriétés" (comme un CHAR(20) ou VARCHAR(30) etc...) des colonnes de chaque table dans le MPD ou lors de la création du code SQL ?
    Normalement, le typage des propriétés (attributs) est à effectuer en amont, lors de la constitution du dictionnaires des données, comme vous l’avez fait à l’occasion de votre 1er message.


    A titre d’exemple, je reprends cet exemple de l’ouvrage de Jean-Patrick Matheron, Comprendre Merise (12e tirage, en 2007) :





    Mais j’ai le sentiment très net de retrouver ce qu’on faisait dans les années soixante-dix, quatre-vingts... Par exemple, la date de commande est ici du type numérique, alors que depuis 1987, avec DB2 (version 1, release 3), on utilisait sans modération le type Date.

    Le typage doit être pris en compte au stade du MCD. De leur côté, les AGL sont plus ou moins bien pourvus.

    Avec DB-MAIN, c’est plutôt spartiate, ça tient du minimum syndical :






    Alors qu’avec PowerAMC la palette est plus fournie :





    Ainsi, des types aussi simples que INT (integer, entier), SMALLINT (entier court) sont omniprésents dans une base de données normalement constituée, et pourtant DB-MAIN ne les propose pas comme types de base (ou alors il y a une subtilité qui m’a échappé). Autrement dit, au stade SQL, il faut reprendre tous les attributs de type NUMERIC(n) et les remplacer par INT ou SMALLINT (je note que si on choisit MySQL, DB-MAIN remplace NUMERIC(n) par INT, mais il ne le fait pas pour PostgreSQL).

    Incidemment, le type INT requiert 4 octets en mémoire et le type SMALLINT 2 octets. Je reprends ici la documentation MS SQL Server (mais le tableau ci-dessous vaut de manière universelle) :






    Pour le type NUMERIC, MS SQL Server ne fait pas dans la dentelle :





    DB2 for z/OS est quand même plus économique, car pour le stockage d’un nombre, il utilise la formule :

    partie entière(p/2)+1

    Où (comme pour MS SQL Server), p est la précision du nombre à stocker.

    J’avoue que je n’ai pas encore décrypté ce qui est écrit pour PostgreSQL :





    Quoi qu’il en soit, il est bon de reprendre les instructions SQL CREATE TABLE, et rectifier ce qui doit l’être...

    Faites-le, je regarderai votre script SQL d’un œil critique...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  5. #25
    Membre à l'essai Avatar de debutant001
    Profil pro
    Eric
    Inscrit en
    Mai 2002
    Messages
    47
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Eric

    Informations forums :
    Inscription : Mai 2002
    Messages : 47
    Points : 24
    Points
    24
    Par défaut
    Bonjour fsmrel,

    Voici le 1er jet de mon script SQL (PostgreSQL) :

    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
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    -- *********************************************
    -- * SQL PostgreSQL generation                 
    -- *--------------------------------------------
    -- * DB-MAIN version: 9.2.0              
    -- * Generator date: Oct 16 2014              
    -- * Generation date: Fri Nov 13 21:37:16 2015 
    -- * LUN file: ~/Projets/Répertoire téléphonique/Répertoire Téléphonique.lun 
    -- * Schema: RépertoireTéléphonique/SQL 
    -- ********************************************* 
    
    
    -- Database Section
    -- ________________ 
    
    create database RepertoireTelephonique;
    
    
    -- Tables Section
    -- _____________ 
    
    create table ADRESSE (
         AdresseId integer not null,
         AdresseRue varchar(65) not null,
         AdresseVille varchar(50) not null,
         AdresseCodePostal varchar(5) not null,
         InscritId integer not null,
         CategorieId smallint not null,
         constraint ID_ADRESSE primary key (AdresseId));
    
    create table CATEGORIE (
         CategorieId smallint not null,
         CategorieLibelle varchar(25) not null,
         constraint ID_CATEGORIE primary key (CategorieId));
    
    create table CATEGORIE_ADRESSE (
         CategorieId smallint not null,
         constraint FKCAT_CAT_ID primary key (CategorieId));
    
    create table CATEGORIE_DIVERS (
         CategorieId smallint not null,
         constraint FKCAT_CAT_1_ID primary key (CategorieId));
    
    create table CATEGORIE_INSCRIT (
         CategorieId smallint not null,
         constraint FKCAT_CAT_2_ID primary key (CategorieId));
    
    create table COMMENTAIRE (
         InscritId integer not null,
         CommentaireContenu varchar(255) not null,
         constraint FKINS_COM_ID primary key (InscritId));
    
    create table INSCRIT (
         InscritId integer not null,
         InscritNom varchar(30) not null,
         InscritPrenom varchar(20) not null,
         InscritDateNaissance date not null,
         TitreId smallint not null,
         CategorieId smallint not null,
         constraint ID_INSCRIT_ID primary key (InscritId));
    
    create table MAIL (
         MailId integer not null,
         MailAdresse varchar(50) not null,
         InscritId integer not null,
         CategorieId smallint not null,
         constraint ID_MAIL primary key (MailId),
         constraint IDMAIL unique (InscritId, MailAdresse));
    
    create table PSEUDO (
         PseudoId integer not null,
         PseudoLibelle varchar(30) not null,
         InscritId integer not null,
         constraint ID_PSEUDO primary key (PseudoId),
         constraint IDPSEUDO unique (InscritId, PseudoLibelle));
    
    create table SITE (
         SiteId integer not null,
         SiteUrl varchar(80) not null,
         InscritId integer not null,
         CategorieId smallint not null,
         constraint ID_SITE primary key (SiteId),
         constraint SID_SITE unique (SiteUrl));
    
    create table TELEPHONE (
         TelephoneId integer not null,
         TelephoneNumero varchar(20) not null,
         TelephoneType varchar(20) not null,
         InscritId integer not null,
         CategorieId smallint not null,
         constraint ID_TELEPHONE primary key (TelephoneId),
         constraint IDTELEPHONE unique (InscritId, TelephoneNumero));
    
    create table TITRE (
         TitreId smallint not null,
         TitreLibelle varchar(15) not null,
         constraint ID_TITRE primary key (TitreId));
    
    
    -- Constraints Section
    -- ___________________ 
    
    alter table ADRESSE add constraint FKPOSSEDER
         foreign key (InscritId)
         references INSCRIT;
    
    alter table ADRESSE add constraint FKADR_CAT
         foreign key (CategorieId)
         references CATEGORIE_ADRESSE;
    
    alter table CATEGORIE_ADRESSE add constraint FKCAT_CAT_FK
         foreign key (CategorieId)
         references CATEGORIE;
    
    alter table CATEGORIE_DIVERS add constraint FKCAT_CAT_1_FK
         foreign key (CategorieId)
         references CATEGORIE;
    
    alter table CATEGORIE_INSCRIT add constraint FKCAT_CAT_2_FK
         foreign key (CategorieId)
         references CATEGORIE;
    
    alter table COMMENTAIRE add constraint FKINS_COM_FK
         foreign key (InscritId)
         references INSCRIT;
    
    --Not implemented
    --alter table INSCRIT add constraint ID_INSCRIT_CHK
    --     check(exists(select * from TELEPHONE
    --                  where TELEPHONE.InscritId = InscritId)); 
    
    alter table INSCRIT add constraint FKETRE
         foreign key (TitreId)
         references TITRE;
    
    alter table INSCRIT add constraint FKINS_CAT
         foreign key (CategorieId)
         references CATEGORIE_INSCRIT;
    
    alter table MAIL add constraint FKAVOIR
         foreign key (InscritId)
         references INSCRIT;
    
    alter table MAIL add constraint FKMAIL_CAT
         foreign key (CategorieId)
         references CATEGORIE_DIVERS;
    
    alter table PSEUDO add constraint FKETRE_SURNOMME
         foreign key (InscritId)
         references INSCRIT;
    
    alter table SITE add constraint FKDISPOSER
         foreign key (InscritId)
         references INSCRIT;
    
    alter table SITE add constraint FKSITE_CAT
         foreign key (CategorieId)
         references CATEGORIE_DIVERS;
    
    alter table TELEPHONE add constraint FKDETENIR
         foreign key (InscritId)
         references INSCRIT;
    
    alter table TELEPHONE add constraint FKTEL_CAT
         foreign key (CategorieId)
         references CATEGORIE_DIVERS;
    
    
    -- Index Section
    -- _____________
    Je dis "1er jet" car je pense qu'il y en aura d'autres... trop de choses nouvelles pour moi pour imaginer une seule seconde réussir du 1er coup !
    (syntaxe PostgreSQL, section "Not implemented" ligne 126, pas de tinyint dans PostgreSQL, présentation particulière du script par DB-Main, noms de clé comme ID_MAIL, IDMAIL ou encore ID_SITE, SID_SITE qui viennent d'on ne sait où...)

    En fait, je crains le pire...

  6. #26
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir Éric,



    Citation Envoyé par debutant001
    syntaxe PostgreSQL, section "Not implemented" ligne 126
    En l'occurrence, DB-MAIN injecte automatiquement une contrainte permettant théoriquement de garantir la cardinalité minimale 1 dans le cas des 1,N.

    Mais à ce jour, seuls les langages basés sur Tutorial D (voyez Databases, Types, and the Relational Model, The Third Manifesto) permettent de garantir formellement les cardinalités 1,N. A cet effet, dans un langage de type D, on définit une contrainte d’égalité entre les projections sur l’attribut InscritId des variables relationnelles (~ tables) INSCRIT et TELEPHONE :


    
    CONSTRAINT RG01 INSCRIT {InscritId} = TELEPHONE {InscritId} ;
    
    
    Considérons maintenant les deux instructions suivantes :

    
    INSERT INSCRIT RELATION {TUPLE {InscritId         123,
                                    InscritNom       'Raoul',
                                    ...  
                                     }
                            } , 
    INSERT TELEPHONE RELATION {TUPLE {TelephoneId       314,
                                      TelephoneNumero   '0123456789',
                                      InscritId         123,
                                   ... 
                                  }
                         } ;  
    
    

    Y figure une subtilité : notez soigneusement que le 1er INSERT est suivi par une virgule, tandis que le 2e est suivi par un point-virgule : le SGBD ne déclenchera les contrôles d’intégrité qu’une fois détecté le point-virgule, ce qui en l’occurrence nous laisse le temps de créer un 1er téléphone avant que la contrainte RG01 ne soit activée.

    Mais avec SQL, cette possibilité n’existe pas, sinon de façon approchée, avec la clause DEFERRED de l’instruction CREATE ASSERTION, laquelle est définie par la norme SQL, mais elle ne figure pas dans la liste des instructions des SGBD SQL du marché, dont PostgreSQL.



    Citation Envoyé par debutant001
    pas de tinyint dans PostgreSQL
    PostgreSQL se plie à la norme SQL, et Tinyint n’y figure pas. Tinyint est une « extension » de MySQL et de SQL Server. A la place, vous pouvez utiliser le type NUMERIC(n) où n représente le nombre de chiffres. Par exemple, si vous codez NUMBER(3), vous autorisez des entiers compris entre -999 et 999. Si vous voulez que les valeurs soient par exemple ≥ 0 et < 256, alors vous ajoutez manuellement une contrainte dans l’instruction CREATE (ou ALTER) TABLE. Supposons qu'on veuille définir un attribut Note pour la table INSCRIT, dont les valeurs soient ≥ 0 et ≤ 20 :

    
    create table INSCRIT (
         InscritId integer not null,
         InscritNom varchar(30) not null,
         InscritPrenom varchar(20) not null,
         InscritDateNaissance date not null,
         TitreId smallint not null,
         CategorieId smallint not null,
         Note number(2) not null,
         
         constraint ID_INSCRIT_ID primary key (InscritId),
         constraint INSCRIT_NOTE_CHK check(Note >= 0 AND Note <= 20)
    );
    
    


    Citation Envoyé par debutant001
    présentation particulière du script par DB-Main, noms de clé comme ID_MAIL, IDMAIL ou encore ID_SITE, SID_SITE qui viennent d'on ne sait où
    Pas de panique !

    Quand on définit une contrainte, DB-MAIN génère un nom pour cette contrainte. Dans l’exemple ci-dessous, j’ai défini une clé alternative pour le numéro de téléphone, et DB-MAIN l’a nommée IDTELEPHONE (beurk...) :





    Rien ne m’empêche de changer ce nom :





    Cela vaut évidemment pour les clés primaires et étrangères. Il arrive que le changement de nom au stade du MCD ne soit pas pris en compte tout de suite au niveau SQL : on rattrape le coup au niveau du diagramme relationnel et en générant à nouveau le script SQL.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  7. #27
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 766
    Points : 52 561
    Points
    52 561
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    ...

    Considérons maintenant les deux instructions suivantes :

    
    INSERT INSCRIT RELATION {TUPLE {InscritId         123,
                                    InscritNom       'Raoul',
                                    ...  
                                     }
                            } , 
    INSERT TELEPHONE RELATION {TUPLE {TelephoneId       314,
                                      TelephoneNumero   '0123456789',
                                      InscritId         123,
                                   ... 
                                  }
                         } ;  
    
    

    Y figure une subtilité : notez soigneusement que le 1er INSERT est suivi par une virgule, tandis que le 2e est suivi par un point-virgule : le SGBD ne déclenchera les contrôles d’intégrité qu’une fois détecté le point-virgule, ce qui en l’occurrence nous laisse le temps de créer un 1er téléphone avant que la contrainte RG01 ne soit activée.

    Mais avec SQL, cette possibilité n’existe pas, sinon de façon approchée, avec la clause DEFERRED de l’instruction CREATE ASSERTION, laquelle est définie par la norme SQL, mais elle ne figure pas dans la liste des instructions des SGBD SQL du marché, dont PostgreSQL.
    Ha si avec SET CONSTRAINT ... DEFERRED / INITIALLY DEFFERD... que PostGreSQL permet d'ailleurs !

    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/ * * * * *

  8. #28
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut assertion, deferred, immediate
    Bonsoir,

    Citation Envoyé par SQLpro
    Ha si avec SET CONSTRAINT ... DEFERRED / INITIALLY DEFFERD... que PostGreSQL permet d'ailleurs !
    Tu vas trop vite Fred, relis la doc de PostgreSQL (à jour en 2015) :

    L’instruction CREATE ASSERTION n’y figure pas. Par ailleurs, l’usage restreint que l’on peut faire avec PostgreSQL de DEFERRED et IMMEDIATE ne convient pas pour garantir une contrainte 1,N. En effet on lit ceci :

    « Currently, only UNIQUE, PRIMARY KEY, REFERENCES (foreign key), and EXCLUDE constraints are affected by this setting. NOT NULL and CHECK constraints are always checked immediately when a row is inserted or modified (not at the end of the statement). Uniqueness and exclusion constraints that have not been declared DEFERRABLE are also checked immediately. »
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  9. #29
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 766
    Points : 52 561
    Points
    52 561
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Bonsoir,



    Tu vas trop vite Fred, relis la doc de PostgreSQL (à jour en 2015) :

    L’instruction CREATE ASSERTION n’y figure pas. Par ailleurs, l’usage restreint que l’on peut faire avec PostgreSQL de DEFERRED et IMMEDIATE ne convient pas pour garantir une contrainte 1,N. En effet on lit ceci :

    « Currently, only UNIQUE, PRIMARY KEY, REFERENCES (foreign key), and EXCLUDE constraints are affected by this setting. NOT NULL and CHECK constraints are always checked immediately when a row is inserted or modified (not at the end of the statement). Uniqueness and exclusion constraints that have not been declared DEFERRABLE are also checked immediately. »

    Oui, mais tu peut le faire par le biais d'une contrainte FK !

    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/ * * * * *

  10. #30
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Bizarre, bizarre !
    Soit le diagramme suivant (notation UML pour les cardinalités) :


    [ T1 ]--1..1-------------1..N--[ T2 ]


    J’insère une ligne dans T1 et je ferme la boutique. La contrainte de cardinalité minimale 1 côté T2 n’est pas respectée (ou alors la norme a procédé à une extension de la clause FOREIGN KEY m’empêchant d’agir ainsi...)
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  11. #31
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 766
    Points : 52 561
    Points
    52 561
    Billets dans le blog
    5
    Par défaut
    [QUOTE=fsmrel;8455256]Soit le diagramme suivant (notation UML pour les cardinalités) :


    [ T1 ]--1..1-------------1..N--[ T2 ]


    Il faut rajouter un FK inverse.

    Exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    [ CLIENT ]--1..1-------------1..N--[ COMMANDE ]
    Un client n'est pas un client s'il n'a pas au moins une facture...

    Avec les transactions déferrable :

    1) Structure des tables

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    CREATE TABLE T_CIENT_CLI
    (CLI_ID           INT PRIMARY KEY,
     FAC_ID_INITIALE  INT NOT NULL REFERENCES T_FACTURE_FAC (FAC_ID) INITIALLY DEFERRED,
     CLI_NOM          VARCHAR(32) NOT NULL);
    
    CREATE TABLE T_FACTURE_FAC
    (FAC_ID        INT PRIMARY KEY,
     CLI_ID        INT NOT NULL REFERENCES T_CIENT_CLI (CLI_ID),
     FAC_DATE      DATE NOT NULL);
    2) pilotage de la transaction

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    BEGIN TRANSACTION;
    
    INSERT INTO T_CIENT_CLI (CLI_ID, CLI_NOM) VALUES (1, 'DUPONT');
    
    INSERT INTO T_FACTURE_FAC (12345, 1, NOW());
    
    UPDATE T_CIENT_CLI AS T
    SET    FAC_ID_INITIALE = 12345;
    
    COMMIT TRANSACTION;
    Le tout gagnerait à être placé dans une procédure stockée....

    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/ * * * * *

  12. #32
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par SQLpro
    Il faut rajouter un FK inverse
    Soit, mais sous réserve que l’intégrité référentielle soit systématiquement respectée, c'est-à-dire qu’on ne puisse pas mélanger les factures des clients : pour cela, il faut veiller à créer la 1re facture d’un client immédiatement après la création de celui-ci, ou placer un SET CONSTRAINT IMMEDIATE au bon endroit.

    J’étends ton exemple, en commençant par créer les clients et en poursuivant avec les factures (test avec PostgreSQL) :

    
    CREATE TABLE T_CIENT_CLI
    (CLI_ID            INT PRIMARY KEY,
     FAC_ID_INITIALE   INT NOT NULL,
     CLI_NOM           VARCHAR(32) NOT NULL);
    
    CREATE TABLE T_FACTURE_FAC
    (FAC_ID        INT PRIMARY KEY,
     CLI_ID        INT NOT NULL REFERENCES T_CIENT_CLI (CLI_ID),
     FAC_DATE      DATE NOT NULL);
     
    ALTER TABLE T_CIENT_CLI ADD CONSTRAINT T_FACTURE_FAC_FK FOREIGN KEY (FAC_ID_INITIALE) REFERENCES T_FACTURE_FAC (FAC_ID) INITIALLY DEFERRED ; 
     
    INSERT INTO T_CIENT_CLI (CLI_ID, FAC_ID_INITIALE, CLI_NOM) VALUES (1, 12345,  'DUPONT');
    INSERT INTO T_CIENT_CLI (CLI_ID, FAC_ID_INITIALE, CLI_NOM) VALUES (2, 54321,  'DURAND');
    
    INSERT INTO T_FACTURE_FAC VALUES (12345, 2, '2015-01-01');
    INSERT INTO T_FACTURE_FAC VALUES (54321, 1, '2015-01-02');
    
    SET CONSTRAINTS T_FACTURE_FAC_FK IMMEDIATE ;
    
    

    Au résultat :

    
    CLI_ID    FAC_ID_INITIALE    CLI_NOM
    ------    ---------------    -------
    1         12345              DUPONT 
    2         54321              DURAND 
    
    
    FAC_ID    CLI_ID    FAC_DATE
    ------    ------    ----------
    12345     2         2015-01-01
    54321     1         2015-01-02
    
    
    =>

    On a mélangé les factures des clients.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  13. #33
    Membre à l'essai Avatar de debutant001
    Profil pro
    Eric
    Inscrit en
    Mai 2002
    Messages
    47
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Eric

    Informations forums :
    Inscription : Mai 2002
    Messages : 47
    Points : 24
    Points
    24
    Par défaut
    Bonsoir à tous,

    Là, vous m'avez perdu ! (déjà qu'avant, sur la fin, c'était plus vraiment très clair dans mon esprit...)

    Ok pour l'utilisation de NUMERIC(n) à la place de tinyint.
    Ok pour la méthode pour renommer les clés alternatives, primaires ou étrangères.
    Merci à vous, fsmrel.

    Par contre, qu'en est-il de ma cardinalité minimale 1 dans le cas des 1,N ????
    Mon "projet" à priori en a besoin… sauf que PostgreSQL ne gère pas…
    Ça veut dire quoi exactement : mon répertoire téléphonique n'est pas réalisable alors ?

    [HS]
    Pour être franc avec vous, j'avoue une nette baisse de motivation à son propos.
    Je pensais m'être lancé dans un petit projet humble, vraiment tout simple... non pas "facile", mais du niveau d'un débutant - comme je le suis.
    Sauf que plus on avance, plus je me rends compte qu'il me manque énormément de notions (même pour un simple répertoire téléphonique), notions que mon bouquin et les tutos suivis jusqu'à présent n'abordent même pas !

    J'étudie de manière autodidacte sur (le peu de) mon temps libre : je pensais pouvoir opérer comme je le fais en programmation, c'est à dire étudier/pratiquer doucement à mon rythme.
    En effet, il n'est pas nécessaire de maîtriser quantité de notions avant de pouvoir créer de petits programmes opérationnels et sympa. (on passe assez rapidement de la théorie à quelque chose de concret)
    Or, dans le domaine des bdds, j'ai la nette impression que ce n'est pas possible avant de maîtriser 100 milliards de notions, méthodes, langages, moteurs, astuces, etc avant d'accoucher d'une petite bdd toute simple...

    Comment faire ?
    Quels conseils pourriez-vous me donner, svp ?
    [/HS]

  14. #34
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par debutant001
    qu'en est-il de ma cardinalité minimale 1 dans le cas des 1,N ????
    Essuyez vos larmes, ne vous prenez pas la tête avec la mise en œuvre en SQL d’une contrainte garantissant la cardinalité minimale 1. L’échange qu’on a eu avec SQLpro a pu vos traumatiser : oubliez cet échange, et faites comme on procédait bien avant que ne naisse SQL (et comme procède encore aujourd’hui l’immense majorité des développeurs), dès que vous avez créé un inscrit, créez ses téléphones dans la foulée :

    INSERT INTO INSCRIT ... ;
    INSERT INTO TELEPHONE ... ;

    SQL (Sorry Query Language) est un langage beaucoup trop lourd (rien que la partie « Foundation », c'est-à-dire le noyau, représente environ 1500 pages ), il est difforme (ça n’est pas la cathédrale de Reims !), ainsi Hugh Darwen le surnomme le Askew Wall... Ces histoires de « SET CONSTRAINT ... DEFERRED / INITIALLY DEFERRED » sont typiques de cette lourdeur : oubliez ces gros mots !

    Votre base de données sera viable, on aménagera les CREATE TABLE pondus par DB-MAIN.

    Quant à maîtriser 100 milliards de de notions, je rappelle que la description du noyau du langage SQL représente environ 1500 pages, autant vous dire que je ne les ai pas lues ! Je ne maîtrise donc que quelques concepts — bien moins que les spécialistes de SQL —, c'est-à-dire ceux de de ces concepts qui sont fondamentaux, indispensables et conformes à la théorie relationnelle, ce qui ne m’a pas empêché de modéliser des bases de données parfois très sensibles (puis de faire le DBA) dans les plus grandes entreprises françaises.

    De mon côté, avant de me lancer dans SQL (dont je ne suis donc pas un spécialiste), je me suis surtout imprégné du Modèle Relationnel de Données, et si vous vous voulez partir sur des bases saines, je vous recommande de découvrir ce modèle : faites l’acquisition de la bible : An Introduction to Database Systems (8th Edition) de C.J. Date. On le trouve d’occasion à partir de US$ 20 euros : cherchez-le par exemple chez AbeBooks, à partir de son ISBN (ISBN10 : 0321197844). Evitez les revendeurs indiens, ils font en général payer un surcoût élevé (et non prévu) pour le poids... Un ouvrage intéressant de Date, pas trop épais : Relational Theory for Computer Professionals.


    Allez, courage ! on tient le bon bout.
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  15. #35
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 766
    Points : 52 561
    Points
    52 561
    Billets dans le blog
    5
    Par défaut
    Pour le contrôle de réciprocité du lien :

    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
    BEGIN TRANSACTION;
    
    INSERT INTO T_CIENT_CLI (CLI_ID, CLI_NOM) VALUES (1, 'DUPONT');
    
    INSERT INTO T_FACTURE_FAC (12345, 1, NOW());
    
    UPDATE T_CIENT_CLI AS T
    SET    FAC_ID_INITIALE = 12345;
    
    IF EXISTS(SELECT CLI_ID, FAC_ID_INITIALE 
              FROM   T_CIENT_CLI AS C
              WHERE  CLI_ID = 1
              EXCEPT
              SELECT CLI_ID, FAC_ID 
              FROM   T_FACTURE_FAC AS C
              WHERE  FAC_ID = 12345)
    THEN
       ROLLBACK;
    ELSE
       COMMIT;
    Le tout gagnerait grandement à être encapsulé dans une procédure !

    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/ * * * * *

  16. #36
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 766
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

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

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 766
    Points : 52 561
    Points
    52 561
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par debutant001 Voir le message
    Bonsoir à tous,

    Là, vous m'avez perdu ! (déjà qu'avant, sur la fin, c'était plus vraiment très clair dans mon esprit...)

    Désolé on voulait pas vous faire de mal !!!!
    Ok pour l'utilisation de NUMERIC(n) à la place de tinyint.
    Ok pour la méthode pour renommer les clés alternatives, primaires ou étrangères.
    Merci à vous, fsmrel.

    Par contre, qu'en est-il de ma cardinalité minimale 1 dans le cas des 1,N ????
    Mon "projet" à priori en a besoin… sauf que PostgreSQL ne gère pas…
    Ça veut dire quoi exactement : mon répertoire téléphonique n'est pas réalisable alors ?

    Il existe une solution plus simple et viable dans tous les bons SGBDR (donc exit MySqLmerde;...)
    L'utilisation systématique de vues.
    Une vue peut être mise à jour comme une table : INSERT, UPDATE, DELETE...
    Dès lors, formez des vues et n'attaquez que vos données à travers les vues.
    Pour obliger votre vue à ne vous montrer que les lignes en lien 1:1 au minima, il suffit de faire une semi jointure...

    Exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    CREATE VIEW V_CLIENT
    AS
    SELECT C.*
    FROM   T_CLIENT_CLI AS C
           JOIN T_FACTURE_FAC AS F
                ON C.CLI_ID = F.CLI_ID;
    Toutes les application devrait être écrites exclusivement à partir de vues et jamais à partir des tables. Cela pose plus de problèmes d'attaquer directement les tables ! L'un des problèmes est la trop forte adhérence au modèle....


    [HS]
    Pour être franc avec vous, j'avoue une nette baisse de motivation à son propos.
    Je pensais m'être lancé dans un petit projet humble, vraiment tout simple... non pas "facile", mais du niveau d'un débutant - comme je le suis.
    Sauf que plus on avance, plus je me rends compte qu'il me manque énormément de notions (même pour un simple répertoire téléphonique), notions que mon bouquin et les tutos suivis jusqu'à présent n'abordent même pas !

    J'étudie de manière autodidacte sur (le peu de) mon temps libre : je pensais pouvoir opérer comme je le fais en programmation, c'est à dire étudier/pratiquer doucement à mon rythme.
    En effet, il n'est pas nécessaire de maîtriser quantité de notions avant de pouvoir créer de petits programmes opérationnels et sympa. (on passe assez rapidement de la théorie à quelque chose de concret)
    Or, dans le domaine des bdds, j'ai la nette impression que ce n'est pas possible avant de maîtriser 100 milliards de notions, méthodes, langages, moteurs, astuces, etc avant d'accoucher d'une petite bdd toute simple...

    Comment faire ?
    Quels conseils pourriez-vous me donner, svp ?
    [/HS]
    Non, pas de découragement ! FSMrel comme moi, nous sommes hyper exigeant, sachant que 99% des bases de données sont mal foutues et que cela peut ne pas être très gênant, si :
    1) il y a peu de données (compensation par le matériel)
    2) il y a peu de concurrence (des temps d'attentes infimes, rarement observables)
    Le problème peut devenir critique si un jour, votre base intéresse la Standard Oil ou la Bell Telphon Companie..... !

    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/ * * * * *

  17. #37
    Membre à l'essai Avatar de debutant001
    Profil pro
    Eric
    Inscrit en
    Mai 2002
    Messages
    47
    Détails du profil
    Informations personnelles :
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Eric

    Informations forums :
    Inscription : Mai 2002
    Messages : 47
    Points : 24
    Points
    24
    Par défaut
    Bonjour fsmrel et SQLpro,

    (=> le retour... car, non, je n'abandonne pas ! Au passage : merci à tous les deux pour vos encouragements !)

    Merci pour ces indications d'ouvrages de référence, c'est sympa !
    En plus, j'ai réussi à les trouver facilement sous forme dématérialisée.

    Par contre, j'ai un souci maintenant : sans parler des 1000 + 280 et quelques pages en anglais à lire (Ah Shakespeare, mon ami de toujours !) à mon boulot on me demande (force ?) de monter en compétences sur... MySQL !
    On vient en effet d'acheter ce livre (http://www.eyrolles.com/Informatique...-9782212143027) qui doit servir un peu de référence aux développeurs (ce n'est pas le seul qui ait été acheté dans ce but) mais aussi de "formation" MySQL pour moi. (en plus de mon travail habituel bien-sur, donc en gros : formation pour le boulot sur mes heures persos, alors que je ne suis pas du tout dév ! )

    Du coup, je ne sais pas quoi faire avec mon super projet qui n'en finit pas : est-ce qu'il faut que je reste malgré tout sur PostgreSQL (au risque de m'emmeler les pinceaux entre PostgreSQL et MySQL) ou vaut-il mieux le basculer vers MySQL (est-ce possible d'ailleurs, vu les diverses contraintes de ce tout petit projet) et tant pis (pour l'instant) pour l'apprentissage perso de PostgreSQL ? (car à priori, "NON, on n'utilisera pas cette usine à gaz de Postgre !" fin de citation...)

    Enfin, certes "on tient le bon bout" mais à force de faire plusieurs de choses en même temps, je ne vois plus ce que - justement - il reste encore à faire pour "terminer" la partie bdd de mon répertoire téléphonique ?

  18. #38
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    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 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Si le chef avait dit : « On laisse M...SQL, et on passe à PostgreSQL », je suppose que vous vous sentiriez un plus serein, mais voilà, le chef a le dernier mot, même si sa compétence en termes de SGBD n’est pas avérée... La prudence recommande de ne pas courir deux lièvres à la fois, et que vous vous soumettiez. Même si c’est avec les larmes aux yeux, concentrez-vous sur le SGBD imposé et l’ouvrage (que n’ai pas lu) écrit par un garçon qui a bonne réputation (et qui à l’occasion pointe le bout de son nez chez Developpez.com).

    En tout cas, à partir du MLD que aurez produit avec DB-MAIN, lors de la génération du code de création des tables SQL, en choisissant MySQL plutôt que PostgreSQL (cf. File > Generate), dans votre cas, la différence ne sera pas bien grande. Vous pourrez ensuite développer les jeux d'essai permettant de secouer la base de données...
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

Discussions similaires

  1. Réponses: 3
    Dernier message: 07/09/2012, 11h52
  2. Dictionnaire des données et le Reporting
    Par RahmaMB dans le forum Approche théorique du décisionnel
    Réponses: 1
    Dernier message: 28/07/2011, 12h11
  3. Réponses: 6
    Dernier message: 13/12/2010, 20h20
  4. Dictionnaire des données
    Par arsenik dans le forum PowerAMC
    Réponses: 3
    Dernier message: 23/06/2010, 23h05
  5. [DF] Dictionnaire des données et Dépendances fonctionnelles
    Par vivicente dans le forum Schéma
    Réponses: 4
    Dernier message: 09/09/2009, 17h16

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