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

Diagrammes de Classes Discussion :

Diagramme de Classes et conception Base de Donnees


Sujet :

Diagrammes de Classes

  1. #41
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 7 077
    Points : 22 512
    Points
    22 512
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par NarumiN Voir le message
    J'ai oublié de préciser que mon projet (site web / application mobile) doit être réalisé avec Java EE et le tout doit virtualiser ou en docker , je dois aussi utiliser des outils devOPS tels que Jenkins et GitHub
    De préférence, je préfère travailler sous linux donc je pense utiliser docker. Dans vos choix, PostgreSQL semble multiplateforme et respectant la norme SQL au mieux. est-ce un bon choix pour un projet web (Java EE) ?
    Je ne me prononcerai pas sur les outils et langages de développement sur lesquels je suis à peu près ignare .
    Cela étant, il me semble qu'on peut avoir n'importe quelle base de donnée sous-jacente à partir du moment où les connecteurs SQL sont disponibles

    Pour le reste, si on vous impose SQLite et/ou du NoSQL, alors il n'y a pas de question à se poser, mais même si vous avez des dizaines de millions de parking à gérer dans le futur, ca reste très modeste pour une base relationnelle et ça ne justifie en rien du NoSQL, surtout pas pour des raisons de rapidité.

  2. #42
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Je ne me prononcerai pas sur les outils et langages de développement sur lesquels je suis à peu près ignare .
    Cela étant, il me semble qu'on peut avoir n'importe quelle base de donnée sous-jacente à partir du moment où les connecteurs SQL sont disponibles

    Pour le reste, si on vous impose SQLite et/ou du NoSQL, alors il n'y a pas de question à se poser, mais même si vous avez des dizaines de millions de parking à gérer dans le futur, ca reste très modeste pour une base relationnelle et ça ne justifie en rien du NoSQL, surtout pas pour des raisons de rapidité.
    Pas de soucis. Vous m'avez énormément aidé et je vous en remercie.


    Citation Envoyé par escartefigue Voir le message
    Oui, ce modèle répond aux règles établies, par contre, la création des vues est un peu prématurée.
    En principe, avec ce modèle, on dérive le script SQL de création des tables (après avoir choisi le SGBD). Ce script est généré automatiquement par la plupart des logiciels de modélisation. C'est le cas de looping.
    Ensuite, il faut créer les index pour les critères de recherche (exemple : recherche par nom de personne, par nom de ville, par département...)
    Quand c'est fait, on se crée un jeu de données avec suffisamment de volume (quelques centaines de milliers de lignes) pour tester les requêtes principales en qualité de résultat et en performances.
    Une fois que tout ça est au point, on peut encapsuler les requêtes dans des vues
    A partir du modèle que vous m'avez grandement aidé à réalisé, je peut créer le script SQL des tables ( pour PostgreSQL) à partir de looping et la fonction Script SQL ?
    Pour la création des index pour les critères de recherche, comment je dois procéder ?

  3. #43
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 7 077
    Points : 22 512
    Points
    22 512
    Billets dans le blog
    2
    Par défaut
    Oui le script SQL proposé par Looping est utilisable en l'état.
    Pour les index, il faut identifier les colonnes ou combinaisons de colonnes qui serviront comme critère de restriction (WHERE) ou de jointure (JOIN)
    Quand c'est fait, on peut créer les index correspondants.
    Pour éviter les erreurs de syntaxe, il faut se référer au manuel de référence du SGBD et de sa version et rechercher l'ordre CREATE INDEX.

    Attention toutefois :
    • un index facilite la recherche seulement s'il concerne des valeurs discriminantes, créer un index sur une colonne ne pouvant prendre que deux ou trois valeurs n'a donc pas d'intérêt (hors index couvrant, mais c'est un autre concept).
    • chaque index supplémentaire pénalise les mises à jour (insert, update et delete) et les servitudes (reorg, rebuild)
    • même quand un index est pertinent, il n'est éligible que si le prédicat est dit "sargable"
      par exemple WHERE ma_colonne=@valeur ou WHERE ma_colonne like 'abcd%' sont sargable si @valeur est du même type que ma_colonne,
      mais WHERE ma_colonne <>@valeur, WHERE ma_colonne like '%abcd% et WHERE SUBSTRING(ma_colonne, 1, 5)=@valeur ne sont pas sargable

    Il faut donc ne créer que les index utiles avec discernement

  4. #44
    Membre expérimenté
    Avatar de Paprick
    Homme Profil pro
    Professeur des Universités
    Inscrit en
    juin 2019
    Messages
    393
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 58
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Professeur des Universités
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2019
    Messages : 393
    Points : 1 580
    Points
    1 580
    Par défaut
    Bonjour,

    Je rejoints escartefigue sur le fait que les index doivent contenir des valeurs discriminantes. D'ailleurs, les meilleurs index sont les clés alternatives.
    Au niveau de Looping, vous pouvez créer ces clés alternatives avec l'option UNIQUE proposée au niveau des rubriques.
    Il est aussi possible de créer des index composés : il faut alors utiliser la zone "Index" prévue à cet effet, zone dont je pourrai vous expliquer le fonctionnement si vous en avez besoin.

    Bonne continuation !
    Patrick Bergougnoux - Professeur des Universités au Département Informatique de l'IUT de Toulouse III
    La simplicité est la sophistication suprême (Léonard de Vinci)
    LIVRE : Modélisation Conceptuelle de Données - Une Démarche Pragmatique
    Looping - Logiciel de modélisation gratuit et libre d'utilisation

  5. #45
    Candidat au Club
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    avril 2021
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : avril 2021
    Messages : 23
    Points : 4
    Points
    4
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    Oui le script SQL proposé par Looping est utilisable en l'état.
    Pour les index, il faut identifier les colonnes ou combinaisons de colonnes qui serviront comme critère de restriction (WHERE) ou de jointure (JOIN)
    Quand c'est fait, on peut créer les index correspondants.
    Pour éviter les erreurs de syntaxe, il faut se référer au manuel de référence du SGBD et de sa version et rechercher l'ordre CREATE INDEX.

    Attention toutefois :
    • un index facilite la recherche seulement s'il concerne des valeurs discriminantes, créer un index sur une colonne ne pouvant prendre que deux ou trois valeurs n'a donc pas d'intérêt (hors index couvrant, mais c'est un autre concept).
    • chaque index supplémentaire pénalise les mises à jour (insert, update et delete) et les servitudes (reorg, rebuild)
    • même quand un index est pertinent, il n'est éligible que si le prédicat est dit "sargable"
      par exemple WHERE ma_colonne=@valeur ou WHERE ma_colonne like 'abcd%' sont sargable si @valeur est du même type que ma_colonne,
      mais WHERE ma_colonne <>@valeur, WHERE ma_colonne like '%abcd% et WHERE SUBSTRING(ma_colonne, 1, 5)=@valeur ne sont pas sargable

    Il faut donc ne créer que les index utiles avec discernement
    Merci a vous.

    Pour choisir les colonnes ou combinaisons de colonnes qui serviront comme critere de restriction ou de jointure. je dois me servir de mes cas d'utilisations et leur description textuelle pour verifier ce que j'ai besoin d'acceder ?

    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
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    Documentation des cas d'utilisation :
    
    =========================================================
    
    Cas d’utilisation : S’authentifier
    Acteurs : Managers et Clients.
    Objectif : Il permet à l’acteur de s’identifier en saisissant son login et mot de passe.
    Précondition : L’acteur doit être présent dans la base de données.
    Postcondition :
    - Acteur authentifié.
    - La page d’accueil s’affiche.
    
    Scénario nominal :
    1. L’acteur ouvre l’application,
    2. Le système affiche la page d’authentification,
    3. L’acteur saisit le login et le mot de passe,
    4. Le système vérifie l’existence des données,
    5. Le système affiche la page d’accueil.
    
    Scénario alternatif :
    1A. Erreur d’authentification : login ou mot de passe non valide.
    Cet enchaînement démarre au point 4.
    1B. Le système affiche un message d’erreur.
    Le scénario reprend au point 2.
    2. Champs obligatoires vides.
    Cet enchaînement démarre au point 4.
    Le scénario reprend au point 2.
    
    
    
    
    ==========================================================
    
    Cas d’utilisation : Ajouter un parking
    Acteurs : Client
    Objectif : Il permet au client de parc d’ajouter un parking dans son profil.
    Précondition : Succès d’authentification.
    Postcondition : Parking ajouté.
    
    Scénario nominal :
    1. Le client choisit d’afficher son profil utilisateur.
    2. Le système affiche le profil utilisateur,
    3. Le client choisit l’ajout d’un nouveau parking,
    4. Le système affiche le formulaire à remplir,
    5. Le client saisit les informations à remplir sur le nouveau parking,
    6. Le système vérifie les données,
    7. Le système enregistre le parking dans la base de données.
    
    
    Scénario alternatif :
    1. Champs obligatoires non valides ou vides.
    Cet enchaînement démarre au point 6.
    2. Le système affiche un message d’erreur.
    Le scénario reprend au point 4.
     
    ============================================================
    Cas d’utilisation : Modifier un parking
    
    Acteurs : Client
    Objectif : Il permet au client de modifier les informations de son parking.
    Précondition :
    - Succès d’authentification.
    - Succès de consultation de la liste de ses parkings.
    Postcondition : Parking modifié.
    
    Scénario nominal :
    1. Le client choisit d’affiche la « Liste de mes parkings »,
    2. Le système affiche la liste,
    3. Le client choisit la modification des informations d’un parking,
    4. Le système affiche le formulaire de modification,
    5. Le client modifie les informations du parking,
    6. Le système demande la validation des modifications,
    7. Le client valide les modifications,
    8. Le système vérifie les données,
    9. Le système enregistre les modifications dans la base de données.
    
    Scénario alternatif :
    1. Champs obligatoires non valides ou vides.
    Cet enchaînement démarre au point 8.
    2. Le système affiche un message d’erreur.
    Le scénario reprend au point 4.
     
    ===========================================================
    Cas d’utilisation : Supprimer un parking 
    
    Acteurs : Client
    Objectif : Il permet au client de supprimer son/ses parkings de son profil utilisateur.
    Précondition :
    - Succès d’authentification.
    - Succès de consultation de la liste de ses parkings.
    Postcondition : Parking supprimé.
    
    Scénario nominal :
    1. Le client choisit d’afficher la « Liste de mes parkings »,
    2. Le système affiche la liste,
    3. Le client choisit la suppression d’un parking,
    4. Le système demande la validation de la suppression,
    5. Le client valide la suppression,
    6. Le système procède à la suppression du parking de la base de données.
    
    Scénario alternatif :
    1. Le client annule la suppression.
    Cet enchaînement démarre au point 4.
    2. Le système affiche une notification.
    Le scénario reprend au point 2.
     
    ================================================================
    Cas d’utilisation : Consulter la liste des annonces de parkings 
    
    Acteurs : Manager et Client
    Objectif : Il permet aux acteurs de consulter la liste des annonces de parkings.
    Précondition : Succès d’authentification.
    Postcondition : Aucune.
    
    Scénario nominal :
    1. L’utilisateur choisit d’afficher la liste des annonces de parkings,
    2. Le système affiche la liste des annonces de parkings,
    3. Le système vérifie le type d’utilisateur connecté (si client ou Manager),
    4. Si l’utilisateur est :
    -	un client, le système fait appel aux cas d’utilisation interne « Réserver un parking ».
    -	un client et le propriétaire du parking, le système fait appel aux cas d’utilisation interne « Modifier une annonce ».
    - 	un Manager, le système fait appel aux cas d’utilisation interne « Modérer une annonce ».
    Scénario alternatif : Aucun.
    
    
     
    ================================================================
    Cas d’utilisation : Réserver un parking
    Acteurs : Client
    Objectif : Il permet à l’acteur de réserver un parking.
    Précondition : Succès d’authentification.
    Postcondition : parking réservé.
    
    Scénario nominal :
    1. Le client choisit d’afficher la « Liste des annonces ».
    2. Le système affiche la liste de ses annonces.
    3. le client choisit de visiter une des annonces.
    4. Le système affiche l’annonce choisie.
    5. Le client choisit de réserver le parking.
    6. Si l’acteur n’est pas le propriétaire du parking, le système affiche le formulaire de réservation.
    7. Le client remplit le formulaire de réservation.
    8. Le système demande la validation des informations saisies.
    9. Le client valide les informations.
    10. Le système vérifie les données.
    11. Le système enregistre la réservation dans la base de données.
    
    
    Scénario alternatif :
    1. Champs obligatoires non valides ou vides.
    Cet enchaînement démarre au point 10.
    2. Le système affiche un message d’erreur.
    Le scénario reprend au point 6.
     
    ================================================================
    Cas d’utilisation : Modifier une annonce de parking
    Acteurs : Client
    Objectif : Il permet à l’acteur de consulter ses annonces de parkings.
    Précondition : Succès d’authentification.
    Postcondition : annonce de parking modifiée.
    
    Scénario nominal :
    1. Le client choisit d’afficher la « Liste de mes annonces ».
    2. Le système affiche la liste de ses annonces.
    3. le client choisit de visiter une de ses annonces.
    4. Le client choisit la modification des informations de l’annonce.
    5. Le système affiche le formulaire de modification.
    6. Le client modifie les informations de l’annonce,
    7. Le système demande la validation des modifications,
    8. Le client valide les modifications,
    9. Le système vérifie les données,
    10. Le système enregistre les modifications dans la base de données.
    
    
    Scénario alternatif :
    1. Champs obligatoires non valides ou vides.
    Cet enchaînement démarre au point 9.
    2. Le système affiche un message d’erreur.
    Le scénario reprend au point 5.
    
    
    
    
    
    
    ================================================================
    Cas d’utilisation : Modérer une annonce de parking
    Acteurs : Manager
    Objectif : Il permet à l’acteur de modérer une annonce.
    Précondition : Succès d’authentification.
    Postcondition : annonce de parking modérée.
    
    Scénario nominal :
    1. Le manager choisit d’afficher la « Liste des annonces ».
    2. Le système affiche la liste des annonces.
    3. le manager choisit de visiter une des annonces.
    4. Le client choisit de modérer l’annonce.
    5. Le système affiche le formulaire de modération.
    6. Le client modifie les informations de l’annonce,
    7. Le système demande la validation des modifications,
    8. Le client valide les modifications,
    9. Le système vérifie les données,
    10. Le système enregistre les modifications dans la base de données.
    
    
    Scénario alternatif :
    1. Champs obligatoires non valides ou vides.
    Cet enchaînement démarre au point 9.
    2. Le système affiche un message d’erreur.
    Le scénario reprend au point 5.

    Citation Envoyé par Paprick Voir le message
    Bonjour,

    Je rejoints escartefigue sur le fait que les index doivent contenir des valeurs discriminantes. D'ailleurs, les meilleurs index sont les clés alternatives.
    Au niveau de Looping, vous pouvez créer ces clés alternatives avec l'option UNIQUE proposée au niveau des rubriques.
    Il est aussi possible de créer des index composés : il faut alors utiliser la zone "Index" prévue à cet effet, zone dont je pourrai vous expliquer le fonctionnement si vous en avez besoin.

    Bonne continuation !
    Bonjour,

    Je prend compte de vos suggestions et conseils.


    Merci beaucoup.

  6. #46
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    7 077
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 7 077
    Points : 22 512
    Points
    22 512
    Billets dans le blog
    2
    Par défaut
    En effet, dans l'exemple fourni, on voit que la recherche se fera sur le login saisi par l'utilisateur.
    Un index sur le login est donc requis.
    Mais comme le login est forcément unique, il y aura par défaut un index existant sur cette colonne *, du coup inutile d'en créer un autre pour ce cas d'utilisation

    * en effet, la plupart des SGBD, sans doute tous, créent un index sur la ou les colonnes faisant l'objet d'une contrainte unique (et donc notamment les PK)

Discussions similaires

  1. Passage d'un diagramme de classe a une base de donnée relationnelle
    Par Midoov dans le forum Diagrammes de Classes
    Réponses: 1
    Dernier message: 07/06/2010, 11h47
  2. diagramme de classe pour un base de donnée
    Par gentelmand dans le forum Diagrammes de Classes
    Réponses: 5
    Dernier message: 23/05/2009, 00h30
  3. conception base de donnees
    Par jean clode dans le forum Modélisation
    Réponses: 9
    Dernier message: 19/07/2007, 11h46
  4. Du diagramme de classe à la conception du code
    Par BRAUKRIS dans le forum Diagrammes de Classes
    Réponses: 8
    Dernier message: 08/05/2005, 18h57

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