Version imprimable
Bonjour,
Dans une application admettant l'architecture suivante :
IHM
couche métier
couche d'accès aux données
couche de persistance de données (BDD)
est ce qu'il convient de concevoir en premier lieu la BDD, ou faut-t-il commencer d'abord par modéliser la couche métier et le schéma de la base est ensuite déductible par un mapping objet/relationnel?
Merci de vos interventions.
personnellement je commence toujours par la base de données
il faut commencé par couche métier
Les données ayant leurs règles de gestion propres, indépendantes des logiciels susceptibles de les utiliser, il faut modéliser en premier les données et surtout pas générer la BDD à partir des classes métier de l'application.
Justement, la responsabilité de la couche métier est de capturer les particularités métier, et notamment les règles de cohérence ou d'intégrité qui le régit, et, ce beaucoup plus fidèlement que ne le permettent les bases de données (cf. business rules engine, dsl, etc).Citation:
Envoyé par CinePhil
Ne pas confondre les règles propres au métier et les règles propres aux données !Citation:
Envoyé par Tommy31
Exemple...
Soit une table de personne (prs_id, prs_nom, prs_prenom, prs_date_naissance, prs_date_enregistrement, prs_date_maj...)
On peut poser comme contrainte sur les données, donc codé dans la BDD, le fait que la date d'enregistrement doit être supérieure à la date de naissance et inférieure à la date de mise à jour si la date de mise à jour n'est pas NULL.
Cette contrainte évitera par exemple qu'une importation de données en masse dans la table entraîne des données incohérentes.
Maintenant si cette table est utilisée pour enregistrer, entre autres, des personnes qui sont des étudiants ayant le niveau BAC+5, l'application pourra poser la contrainte métier sur le fait que la date de naissance de l'enregistrement d'un de ces étudiants lui donne un âge d'au moins 20 ans par exemple (BAC à 15 ans c'est déjà une performance rarissime !).
Mais si cette table enregistre également les enfants du personnel, cette contrainte métier d'ancienneté de la date de naissance ne peut pas être posée sur la colonne de la table.
Quand aux contraintes d'intégrité, elles seront beaucoup plus efficaces et incontournables par le mécanisme des clés étrangères par les contraintes CHECK et par les triggers dans la BDD que par un logiciel utilisateur de la BDD. Là encore, attention aux insertions ou aux modifications externes au logiciel ! Le SGBD ne laissera rien passer, quel que soit le moyen d'alimentation des données. Le logiciel ne peut contrôler que ce qu'il gère au moment où il le gère.
Couche Métier en premier mais modèle des entités métiers en premier.
@CinePhil
Cette phrase n'a pas de sens.Citation:
Ne pas confondre les règles propres au métier et les règles propres aux données !
Les règles métier sont essentiellement des règles portant sur les données et l'exemple que tu donnes en est un bon exemple.
Parmi les règles métier, on a en gros 2 catégories de règles.
1- Les règles qui sont exprimables directement dans le modèle statique (le modèle des entités métier ou le MCD dans le monde Merise). On retrouve l'expression de ces règles au travers des relations que l'on a créé ou pas créé. Héritage et associations sont l'expression de règles métier et qui se matérialisent in fine dans le schéma de la base de données. Les multiplicités que l'on met aux extrémités des associations (rôles UML) sont aussi des règles métier. Quand on met une multiplicité du genre 1..2 du côté de l'entité "Dossier" sur l'association entre "Personne" et "Dossier", on dit qu'une Personne doit avoir au moins un Dossier et au plus 2; c'est une règle de gestion. D'autres règles pourront/devront s'exprimer via des mécanismes plus "complexes" comme un langage type OCL.
2- Les règles métier "dynamiques" qui utilisent les données mais qui ne les contraingnent pas directement. Du genre, dans un traitement on peut vouloir dire : "Si la Personne est majeure, lui envoyer un email de confirmation, sinon envoyer une confirmation par email à ses parents".
La 1e catégorie de règles peut en majorité se retrouver sous forme de contraintes dans le SGBD, mais pas toutes.
La seconde catégorie de règles ne se retrouve pas dans le SGBD mais dans le code de l'application.
Donc comme on fait avant tout des applications "métier", il est donc primordial de commencer à savoir ce que l'on a à faire d'un point de vue métier. Ce n'est qu'ensuite que l'on regarde comment, en fonction de ces règles, la base de données peut être construite. Car s'il y a des règles de passage "MCD - MPD" ou "Modèle d'entités - MPD" (c'est pareil dans les 2 cas, tout dépend du vocabulaire que vous employez), l'usage des données par l'application mais aussi les tests de performances doivent vous guider dans l'optimisation du schéma de la base.
Les deux approches sont possibles. Fais une recherche sur "top down" et "bottom up" pour connaitre les avantages de chacune. On peut aussi faire du "middle out" ou du "meet in the middle" lorsqu'il y a une couche de mapping objet-relationnel.Citation:
Envoyé par Bassas
Non mais sans rire, on définit d'abord ce que l'on a à gérer = le métier. Ensuite la base est créée.Citation:
Envoyé par Luckyluke34
Tiens prenons un exemple :
Voici mon problème : "je dois gérer....." quelle doit être la base de données pour .......... ?
Le premier qui me sort la base de données appropriée gagne une ferrari, une vraie, promis ! Allé c'est parti :mouarf:
MCD :Citation:
Envoyé par ego
Ensemble -1,n----Constituer----0,n- Point
Tables :
Point (pt_id, pt_coord_x, pt_coord_y...)
Ensemble (ens_id...)
Constitution (cns_id_ensemble, cns_id_point)
En rouge la Ferrari STP ! :mrgreen:Citation:
Le premier qui me sort la base de données appropriée gagne une ferrari, une vraie, promis ! Allé c'est parti :mouarf:
Bravo !!!! :ccool:
C'est pas ça :oops::mouarf:
Une autre tentative :aie: