Version imprimable
Bonjour,
dans le cadre de mon projet, j'utilise une base de données NoSQL (CouchDB en loccurence), ma question ne concerne pas tellement la conception en elle même mais les différent diagram de conception que je dois mettre dans mon rapport.
puisque le modéle relationel n'est plus d'actualité et que la partie base de données doit être présente, quel diagram me conseillez vous d'utilisez.
Merci
Salut,
La conception est une activité qui va permettre de "construire" l'application: on fait les plans de... qui vont nous permettre de... Si vous racontez comment vous avez construit votre application, ce n'est plus de la conception mais une "description" de "l'existant".
CIFS/NFS/SQL/NoSQL... sont des technologies qui permettent de réaliser les fonctions de persistance avec des avantages et des inconvénients suivant le domaine applicatifs.
La mise en œuvre et l'intégration sont différents et propre à chaque techno.
Mais "in fine" çà permet à l'application d'avoir des "tuyaux" qui lui permettront de stocker et récupérer des informations.
Ces informations sont à priori _spécifiques_ et méritent (peut être) d'être décrites.
Quelle que soit la techno, il faut bien décrire les "keys/values" associées aux documents ou aux enregistrements utilisés en donnant le label des keys, la description de ce que c'est côté "métier", le format de la représentation, un exemple, ... Il faut aussi mentionner les traitements applicatifs qui dépendent de ces données.
Diagramme de classe, tableaux construits avec votre tableur préféré,... sont utilisables.
Cordialement,
- W
PS: Nous ne savons pas obtenir avec NoSQL le même niveau d'intégrité de données que nous pouvons avoir avec SQL. Cette intégrité de données suppose une "centralisation" incompatible avec le "scale-out" nécessaire à des applications Web et que permet NoSQL.
Merci pour la mise au point :)
En réalité, la conception est déja fini, la base de données n'étant pas terriblement complexe,
(une dixaine de tables, ou documents, comme on les appelle sous couchdb).
Je me demandais s'il n'y'avait pas une méthode standard pour décrire ce genre de structure.
Le diagramme de classe était ma premiére idée, mais CouchDB n'est à priori pas une base orienté objet (d'aprés le site officiel).
Un document est en fait une sorte de dictionaire (structure de données), donc la base peut être représenté en tant qu'un dictionaire de dictionaires. Une idée sur comment représenter cela?
Je ne cherche que la représentation en diagramme, la partie description textuelle en découlera automatiquement :)
Merci
Salut,
Les attributs d'une classes peuvent représenter les KV d'un document comme ils peuvent représenter ceux d'un schéma d'une relation de BDD relationnelle ou d'un "objet" d'un langage POO.Citation:
Envoyé par lcfseth
Si vous ne savez pas ce qu'est un diagramme de classe: contentez vous d'un tableau simple.
- W
Merci, j'ai fini par trouver ce que je cherchais. Une représentation en modèle clé/valeur.
Je met le lien au cas ou d'autre personnes ont le même probléme.
http://www.blog-nouvelles-technologi...iller-en-2011/
J'avoue qu'un classe peut tout à fait représenter un document. Cependant, il y'a une énorme différence entre les deux (notions d'héritage, d'interface...) et l'utilisation d'un diagramme de classe provoquera automatiquement des interrogations et des remarques négative (un diagramme de classe sur des entités qui n'en sont pas).
Merci pour l'attention
Salut,
Vous avez trouvé une représentation qui vous convient, tant mieux.
Une classe est avant tout une "boîte" dans laquelle peuvent être insérés attributs et méthodes.Citation:
Envoyé par lcfseth
Si vous utilisez la boîte pour représenter un schéma de base de donnée (des relations), vous n'aurez besoin que de mentionner les attributs, certains pouvant représenter des PK ou autre association.
Vous pouvez très bien représenter un schéma XML avec ce genre de boîte.
Dans les deux cas, vous cannibalisez l'outil classe et diagramme de classe pour construire une représentation "border line" vis à vis d'UML.
Le seul intérêt de procéder ainsi n'est pas que cela ressemble à de l'UML mais l'intégration du schéma dans l'outil de gestion projet UML pour avoir des relations de dépendance, de traces, réalisation entre cette chose et d'autres composants du projet.
Si le but est simplement de documenter les champs, leur domaine et leur type, je persiste à dire qu'un tableau suffira largement.
- W