Aide sur la création d'une bdd sous MySQL

Shellai-93 · 15/02/2006, 15h58

Bonjour,

Edit: je laisse mon message initial, je devais faire une base sous Access, j'ai changer d'idée et décider de la faire sous My SQL.

Je suis actuellement étudiant en alternance, dans le cadre de mon travail en entreprise, on me demande de crée une bdd sous Access.
Le devellopement de base de données n'étant pas mon domaine de prédilection, je me permet de poster un message ici pour recevoir l'aide de personne ayant de plus grande facilité et qui pourront m'aiguiller.

La base de donnée concerne des contentieux fait à certains clients, on m'a fourni une liste d'éléments, les voici :

A partir de cela, j'ai reçu 2,3 conseil d'un ami, il m'a donc conseiller de faire 3 tables

_ Une table Client ( ID_Client;Nom_Client;Prenom_Client; num_lot)
_ Une table Contentieux ( ID_conten;#CdtypConten; #ID_Client; ...)
_ Une table Type Contentieux ( CdtypConten; Nom;...)

Ce que je n'arrive pas à comprendre, c'est la facon dont on gere les informations concernant un type de contentieux, exemple ( à voir en rapport avec l'image) :
CdTypConten = 1 = Demande d'engagement de procédure => date édition, transmission traitement, montant dette

( mon interrogation porte sur ce que j'ai mis en italique ).

PS: j'immagine que c'est surement simple pour vous, mais pas tellement pour moi qui ne fait qu'apprendre, et qui ne sais pas encore rouler sans les petites roulettes

J'espere ne pas avoir etait trop long, et que certains auront le courage de me lire... voir de m'aider

Arkham46 · 15/02/2006, 18h02

slt,

vu que les champs sont peu nombreux tu peux mettre dans la table des contentieux toutes les informations possibles

ensuite tu adaptes les différents formulaires en fonction du type de contentieux

per exemple si type = 1 alors il n'y a pas de "réception avocat" donc tu masques ou tu grises le champ

En résumé c'est à peu près comme ça que je le vois :
1 - mettre tous les champs possible dans la table
2 - restreindre l'affichage des formulaires en fonction du type de contentieux

C'est peut-être pas si simple, ça dépend aussi des différents traitements que tu as a faire sur les données.

Il faudrait peut-être prévoir une table de paramètrage supplémentaire pour définir par type de contentieux la liste des champs à gérer et éventuellement des codes spécifiants les calculs à faire si ceux-ci différent d'un type de contentieux à l'autre.
Ceci afin de gérer dynamiquement l'affichage et les traitements, ne pas écrire du code illisible avec des dizaines de IF, et pouvoir éventuellement par la suite rajouter un type de contentieux sans toucher au code.

Si les traitements ne différent pas trop (le "pas trop" est très subjectif...) d'un type à l'autre c'est faisable.

Bon courage.

Shellai-93 · 04/04/2006, 11h30

Est-il possible qu'un modérateur déplace mon sujet qui n'a plus sa place dans la section Access, mais plutot dans la section My Sql ou SGBD. Merci au modérateur.

Bonjour,

Merci pour la réponse ( que j'avais deja lu ).

J'ai du temps pour me remettre sur la question, j'ai donc utiliser le logiciel DB designer pour ensuite crée ma base sous MySql.

Voila un premier jet, pouvez vous me conseillez, m'aiguillez.

Maximilian · 04/04/2006, 12h37

Salut,

Pourquoi ne pas faire un schéma entité-association (design conceptuel) au lieu de passer directement aux tables (design logique et physique) ?

Ca permettrait de mieux dégager ce qui dans la consigne relève de l'entité, de l'association, de la propriété, éventuellement les héritages...

Shellai-93 · 04/04/2006, 15h32

Alors, j'essaye comme je peux

Voila un premier jet pour un schéma entité-association :

beaba · 04/04/2006, 18h26

Shellai, mets toujours un Identifiant dans les attributs de tes entités.
Sinon, tu as reçu un super conseil de maximilian : fignole ton MCD, passe au modèle relationnel et ensuite tu as directement la structure de tes tables et tu ne peux pas te tromper.
Bon courage
Béaba

Shellai-93 · 10/04/2006, 16h36

( je débute, donc je suis pas encore au point au niveau des méthodes à suivre, merci en tout cas pour vos conseils méthodologique )

J'ai donc mis des identifiants :

Maximilian · 10/04/2006, 17h22

Le problème c'est que le document est loin d'être clair :

Pourquoi (date, montant, dette) reviennent tout le temps ?
Est-ce qu'il faut garder un historique complet de l'évolution des dettes et des procédures engagées concernant chaque contentieux ?
Y-a-t'il un lien chronologique ou logique entre ces différentes procédures ?

Autant d'éléments qui vont déterminer le cahier des charges de l'application et à fortiori le modèle de données.
Je ne sais pas si tu as eu l'opportunité de te faire expliquer plus en détail le système des contentieux et les besoins de la boîte, mais sans une puissante boule de cristal on ne peut objectivement rien construire de valable à partir de ce bout de papier seul...

Shellai-93 · 11/04/2006, 12h15

Hello,

Oui en effet désolé c'est loin d'etre explicite pour vous.

Donc, date, montant, dette.. reviennent constamment, car comme tu la deviné il faut gardé un historique.

Pour donner un exemple, la liste des contentieux voir 1er document :
_ Demande d'engagement de procédure
_ Assignation
_ ...

Ses evenements arrivent de facon chronologique, l'un aprés l'autre et on doit garder à chaque évenement la date, le montant de la dette à l'instant t, etc.
Mais il y'a des exceptions, des évenement dont les informations puissent etre saisie ultérieurement, de facon graphique il faudrait une case grisée qui puisse etre saisisable plus tard.

Maximilian · 11/04/2006, 16h33

OK. Il reste encore des points obscurs, notamment en ce qui concerne les mises en demeures et les honoraires (peut-il y en avoir plusieurs pour un contentieux ?) mais je pense qu'on peut déjà dégager ces entités :

- Client
- Contentieux
- Evenement

Le souci semble être de modéliser correctement les différents types d'événements (assignation, audience, saisie...), à ce titre il parait judicieux d'utiliser un héritage.

Au niveau base de données ça donnerait une table mère événement qui regrouperait les colonnes communes (date, montant, dette) et le type d'événement, ainsi qu'une table fille pour chaque type d'événement spécifique qui ne rentre pas exactement dans ce moule (saisie, recours complémentaire...)

Cf http://laughingmeme.org/articles/2004/08/14/mysql-and-the-case-for-class-table-inheritance

http://sqlpro.developpez.com/cours/modelisation/heritage/

Shellai-93 · 12/07/2006, 17h05

Bonjour,

J'ai du laisser le projet de coté pendant quelque mois, j'ai maintenant le temps de m'y remettre ( enfin je dois surtout le bouclé pour Septembre...) mais bref.

Merci pour ton aide Maximilian, j'espere que tu aura un peu de temps à me consacré à nouveau.

Donc, j'ai suivi les liens que tu as donnée expliquant le principe d'héritage, je pense l'avoir compris.

Cela dit, ce que je ne comprend pas c'est pourquoi je devrais mettre dans la table evenement à la fois "date, montant dette,..." et aussi le type d'evenement.

D'aprés ce qu'il me semble avoir compris de la mécanique d'héritage.. il ne faudrait pas plutot mettre le type d'evenement ( par exemple Assignation ou Audience ou Jugement) dans la table Contentieux qui sera fille de la table mere Evenements. ?

Shellai-93 · 31/07/2006, 15h39

up, besoin d'une petite aide pour les tables d'héritage

Shellai-93 · 07/08/2006, 00h33

C'est encore moi...

Que pensez vous de cela, j'ai utiliser la table Evenement comme table mere de la table fille Contentieux.

J'ai utilisé le principe d'héritage de sorte à pouvoir repeter à chaque contentieux les evenements date, montant dette..

Je n'ai biensur pas remplis complétement mes tables.

J'admet, je patauge un peu pour ma 1ere bdd...

Maximilian · 07/08/2006, 09h10

Citation:

Envoyé par Shellai-93

Cela dit, ce que je ne comprend pas c'est pourquoi je devrais mettre dans la table evenement à la fois "date, montant dette,..." et aussi le type d'evenement.

C'est une question de commodité, par exemple pour chercher les 3 derniers événements associés à un client.

Si tu fais une table par type d'événement (assignation, audience, jugement, saisie...) une telle recherche va être fastidieuse. Alors que là il te suffit de chercher dans la table événement les 3 derniers et leur type sera indiqué dans la colonne type.

Au besoin tu vas ensuite chercher les infos complémentaires dans les tables filles qui héritent d'événement (la donnée "réception avocat" pour un événement de type Assignation par exemple).

Maintenant tout ne doit pas forcément hériter d'Evénement, ça dépend de ton contexte. Ex : Honoraires n'est pas vraiment un événement, ça peut être une table à part (si 1 contentieux = plusieurs honoraires) ou intégré dans la table contentieux.

L'héritage ne se situe donc pas entre contentieux et Evenement comme dans ton schéma, mais entre Evénement et des tables d'événements particuliers...

Shellai-93 · 08/08/2006, 16h15

Hum, je me rend compte à chaque fois à quel point je n'ai pas encore la logique.. base de données.. bon ca viendra!

Bon, je vais pas faire de schémas inutiles à chaque fois donc j'ai pondu ça:

Client [#numero_client; Foyer; Nom; Prenom; Lot ]
Contentieux[#ID_conten; numero_client;
Evenement[ID_conten; Demande_engagement; Assignation; Audience; ...; Classement_Dossier]
Date[ID_conten; date; date_edition; date_demande; date_envoie]
Montant[ID_conten; montant_dette; montant_indeminisation]
Honoraires [#ID_honoraire; tiers, date_paiement, montant]

d'aprés ce que tu m'as dit, j'ai essayé de repensé la chose en créant les tables (sur le papier, hein) date et montant qui sont des tables filles de la table evenement.
Et j'ai crée la table honoraire, qui n'a pas besoin d'hérité de la table evenement.

Tu peux me dire ce que tu en penses

Maximilian · 08/08/2006, 17h33

Ce n'est pas tout à fait ça.
Prenons un exemple simple présenté dans le lien que je t'avais donné :

Ici, un individu est un type de contact particulier avec des données propres (firstName et lastName) et une organisation est un type de contact particulier possédant un orgName. Individu et organisation héritent de contact.

Chaque contact occupera donc d'une part une ligne dans la table contact, et d'autre part, selon si c'est un individu ou une organisation, une ligne dans la table individu ou organisation.
Comment faire le rapprochement entre les deux pour récupérer toutes les données dont on a besoin ? Premièrement la colonne contactType nous indique dans quelle table fille chercher, et deuxièmement un contact déterminé a le même identifiant dans la table Contact et dans Individu ou Organisation.

Mais on peut aussi très bien imaginer qu'il y ait d'autres colonnes dans la table contact (par exemple : une donnée commune à tous les contacts comme l'email) et que certains contacts restent génériques, ils ne sont ni dans Individu ni dans Organisation et ont seulement ces données de base.

C'est ce qu'on peut faire avec ton modèle, un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Evenement (id_evenement, date, montant_dette, type_evenement)
 
Assignation (id_evenement, reception_avocat)
RecoursConmplementaire (id_evenement, montant_indemnisation)
RecoursContentieux (id_evenement, montant_indemnisation)
...

Bref tous les événements qui ont autre chose que les colonnes de base Date et Montant_dette (ce sont les colonnes qui reviennent le plus, celles qu'on peut "factoriser') sont déclinés dans des tables filles qui héritent de Evenement...

C'est plus clair ?

Shellai-93 · 10/08/2006, 14h45

Ouais c'est plus clair merci, c'est pas que c'était pas clair avant, juste que j'avais mal compris la facon de procéder ( rassembler les entités identiques )

Donc, ca me donnerait ça, si j'ai bien compris :

Client(#numero_client, Foyer, Nom, Prenom, Lot)
Contentieux(#ID_conten; numero_client) (J'ai un point d'ombre concernant l'utilité/fonction de cette table.. et comment la remplir)

Evenement (#id_evenement, date, montant_dette, type_evenement)
Demande_eng_proc (id_evenement, transmission, traitement)
Assignation (id_evenement, reception_avocat)
Recours_comp (id_evenement, montant_indemnisation)
Recours_contentieux (id_evenement, montant_indemnisation)
Indemnisation (id_evenement, montant_indemnisation)
Imputation_art700 (id_evenement, references)
Autres_imputations (id_evenement, references)

Concernant la partie que j'ai mis en marron, donc comme ton exemple du contact, là ce qui permettra de savoir si il faut aller dans telle ou telle table fille ca sera l'attribu "type_evenement" de la table mere Evenement...?
Mais dans le cas où c'est un evenement comme Audience qui ne fait pas appel à une table fille, comment on le gere...? on va simplement remplir le champs type_evenement qui ne sera donc pas le nom d'une des tables filles.. et il saura qu'il a pas besoin "d'aller plus loin" ?

Enfin j'imagine que ça, je devrais le gerer lors de la programmation sql...?

En tout cas merci pour tes explications, j'apprend beaucoup, j'aurai pas eu cette patience avec un boulet comme moi

Edit: ah oui, je voulais également te demander si il n'était donc pas possible de rassembler les tables filles suivantes :

Recours_comp (id_evenement, montant_indemnisation)
Recours_contentieux (id_evenement, montant_indemnisation)
Indemnisation (id_evenement, montant_indemnisation)

&

Imputation_art700 (id_evenement, references)
Autres_imputations (id_evenement, references)

Ne pourrais-je pas y ajouter un attribut comme type_evenement, simplement pour préciser si c'est par exemple un recours complémentaire ou un recour contentieux ?

Donc :

Indemnisation ( id_evenement, montant_indemnisation, type_evenement2)
&
Reference( id_evenement, references, types_evenement3)

Maximilian · 10/08/2006, 15h21

Citation:

Envoyé par Shellai-93

Donc, ca me donnerait ça, si j'ai bien compris :

Client(#numero_client, Foyer, Nom, Prenom, Lot)
Contentieux(#ID_conten; numero_client) (J'ai un point d'ombre concernant l'utilité/fonction de cette table.. et comment la remplir)

Evenement (#id_evenement, date, montant_dette, type_evenement)
Demande_eng_proc (id_evenement, transmission, traitement)
Assignation (id_evenement, reception_avocat)
Recours_comp (id_evenement, montant_indemnisation)
Recours_contentieux (id_evenement, montant_indemnisation)
Indemnisation (id_evenement, montant_indemnisation)
Imputation_art700 (id_evenement, references)
Autres_imputations (id_evenement, references)

Exactement. La table contentieux est là tout simplement parce qu'il peut y avoir plusieurs contentieux par client (enfin, j'imagine) et qu'à un contentieux se rattachent plusieurs événements. Donc tu peux ajouter une clé étrangère id_contentieux à la table événement.

Citation:

Envoyé par Shellai-93

Concernant la partie que j'ai mis en marron, donc comme ton exemple du contact, là ce qui permettra de savoir si il faut aller dans telle ou telle table fille ca sera l'attribu "type_evenement" de la table mere Evenement...?
Mais dans le cas où c'est un evenement comme Audience qui ne fait pas appel à une table fille, comment on le gere...? on va simplement remplir le champs type_evenement qui ne sera donc pas le nom d'une des tables filles.. et il saura qu'il a pas besoin "d'aller plus loin" ?

Oui. Par exemple un jugement aura come type d'événement "Jugement" et cela permettra de savoir si l'affaire est déjà passée en jugement, éventuellement combien de fois... (après je ne connais pas les détails de la procédure)

Citation:

Envoyé par Shellai-93

Edit: ah oui, je voulais également te demander si il n'était donc pas possible de rassembler les tables filles suivantes :

Recours_comp (id_evenement, montant_indemnisation)
Recours_contentieux (id_evenement, montant_indemnisation)
Indemnisation (id_evenement, montant_indemnisation)

&

Imputation_art700 (id_evenement, references)
Autres_imputations (id_evenement, references)

Ne pourrais-je pas y ajouter un attribut comme type_evenement, simplement pour préciser si c'est par exemple un recours complémentaire ou un recour contentieux ?

Si tu sens que ces événements sont de même nature, pourquoi pas, mais 2 niveaux d'héritage ça va compliquer les requêtes. Il vaut peut-être mieux commencer par plus simple...

Shellai-93 · 10/08/2006, 18h00

Ok pour la table contentieux, c'est capish.

Concernant le 2nd niveau d'héritage, dans ce cas je vais laisser tel quel alors, j'ai pas spécialement d'interet à regrouper les tables finalement, et si ca simplifie les requetes, on va laisser comme ça

En reprennant tout du début, j'en arrive donc à cela, niveau MCD :

En fait, j'ai un gros doute sur les cardinalités...
_ De client à contentieux : 1,n car un client peut avoir 1 ou plusieurs contentieux en cours
_ De contentieux à client : 1,1 car un contentieux ne peux etre identifié qu'a un seul client...?
_ De contentieux à Evenement : 1,n car d'un contentieux peux resulter plusieurs evenements
_ D'Evenement à contentieux : 1,n, car un evenement peut etre applicable à different contentieux

Maximilian · 11/08/2006, 10h28

Citation:

Envoyé par Shellai-93

_ De client à contentieux : 1,n car un client peut avoir 1 ou plusieurs contentieux en cours

Oui.

Citation:

Envoyé par Shellai-93

_ De contentieux à client : 1,1 car un contentieux ne peux etre identifié qu'a un seul client...?

Ca je n'en sais rien, c'est une règle de gestion qui dépend de ton contexte

Citation:

Envoyé par Shellai-93

_ De contentieux à Evenement : 1,n car d'un contentieux peux resulter plusieurs evenements

Oui.

Citation:

Envoyé par Shellai-93

_ D'Evenement à contentieux : 1,n, car un evenement peut etre applicable à different contentieux

Encore une fois, c'est à toi de le déterminer. Est-ce qu'une seule saisie peut concerner plusieurs dossiers en cours, est-ce qu'un jugement peut porter sur plusieurs affaires ? ...

15/02/2006, 15h58	#1
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	Aide sur la création d'une bdd sous MySQL Bonjour, Edit: je laisse mon message initial, je devais faire une base sous Access, j'ai changer d'idée et décider de la faire sous My SQL. Je suis actuellement étudiant en alternance, dans le cadre de mon travail en entreprise, on me demande de crée une bdd sous Access. Le devellopement de base de données n'étant pas mon domaine de prédilection, je me permet de poster un message ici pour recevoir l'aide de personne ayant de plus grande facilité et qui pourront m'aiguiller. La base de donnée concerne des contentieux fait à certains clients, on m'a fourni une liste d'éléments, les voici : A partir de cela, j'ai reçu 2,3 conseil d'un ami, il m'a donc conseiller de faire 3 tables _ Une table Client ( ID_Client;Nom_Client;Prenom_Client; num_lot) _ Une table Contentieux ( ID_conten;#CdtypConten; #ID_Client; ...) _ Une table Type Contentieux ( CdtypConten; Nom;...) Ce que je n'arrive pas à comprendre, c'est la facon dont on gere les informations concernant un type de contentieux, exemple ( à voir en rapport avec l'image) : CdTypConten = 1 = Demande d'engagement de procédure => date édition, transmission traitement, montant dette ( mon interrogation porte sur ce que j'ai mis en italique ). PS: j'immagine que c'est surement simple pour vous, mais pas tellement pour moi qui ne fait qu'apprendre, et qui ne sais pas encore rouler sans les petites roulettes J'espere ne pas avoir etait trop long, et que certains auront le courage de me lire... voir de m'aider
	00

04/04/2006, 12h37	#4
Maximilian Provisoirement toléré Inscription : juin 2003 Messages : 2 622 Détails du profil Informations forums : Inscription : juin 2003 Messages : 2 622 Points : 2 505 Points : 2 505	Salut, Pourquoi ne pas faire un schéma entité-association (design conceptuel) au lieu de passer directement aux tables (design logique et physique) ? Ca permettrait de mieux dégager ce qui dans la consigne relève de l'entité, de l'association, de la propriété, éventuellement les héritages... __________________ Pensez au bouton
	00

10/04/2006, 17h22	#8
Maximilian Provisoirement toléré Inscription : juin 2003 Messages : 2 622 Détails du profil Informations forums : Inscription : juin 2003 Messages : 2 622 Points : 2 505 Points : 2 505	Le problème c'est que le document est loin d'être clair : Pourquoi (date, montant, dette) reviennent tout le temps ? Est-ce qu'il faut garder un historique complet de l'évolution des dettes et des procédures engagées concernant chaque contentieux ? Y-a-t'il un lien chronologique ou logique entre ces différentes procédures ? Autant d'éléments qui vont déterminer le cahier des charges de l'application et à fortiori le modèle de données. Je ne sais pas si tu as eu l'opportunité de te faire expliquer plus en détail le système des contentieux et les besoins de la boîte, mais sans une puissante boule de cristal on ne peut objectivement rien construire de valable à partir de ce bout de papier seul... __________________ Pensez au bouton
	00

11/04/2006, 16h33	#10
Maximilian Provisoirement toléré Inscription : juin 2003 Messages : 2 622 Détails du profil Informations forums : Inscription : juin 2003 Messages : 2 622 Points : 2 505 Points : 2 505	OK. Il reste encore des points obscurs, notamment en ce qui concerne les mises en demeures et les honoraires (peut-il y en avoir plusieurs pour un contentieux ?) mais je pense qu'on peut déjà dégager ces entités : - Client - Contentieux - Evenement Le souci semble être de modéliser correctement les différents types d'événements (assignation, audience, saisie...), à ce titre il parait judicieux d'utiliser un héritage. Au niveau base de données ça donnerait une table mère événement qui regrouperait les colonnes communes (date, montant, dette) et le type d'événement, ainsi qu'une table fille pour chaque type d'événement spécifique qui ne rentre pas exactement dans ce moule (saisie, recours complémentaire...) Cf http://laughingmeme.org/articles/2004/08/14/mysql-and-the-case-for-class-table-inheritance http://sqlpro.developpez.com/cours/modelisation/heritage/ __________________ Pensez au bouton
	00

15/02/2006, 18h02	#2
Arkham46 Responsable Access Inscription : septembre 2003 Messages : 4 300 Détails du profil Informations personnelles : Localisation : France, Loiret (Centre) Informations forums : Inscription : septembre 2003 Messages : 4 300 Points : 7 936 Points : 7 936	slt, vu que les champs sont peu nombreux tu peux mettre dans la table des contentieux toutes les informations possibles ensuite tu adaptes les différents formulaires en fonction du type de contentieux per exemple si type = 1 alors il n'y a pas de "réception avocat" donc tu masques ou tu grises le champ En résumé c'est à peu près comme ça que je le vois : 1 - mettre tous les champs possible dans la table 2 - restreindre l'affichage des formulaires en fonction du type de contentieux C'est peut-être pas si simple, ça dépend aussi des différents traitements que tu as a faire sur les données. Il faudrait peut-être prévoir une table de paramètrage supplémentaire pour définir par type de contentieux la liste des champs à gérer et éventuellement des codes spécifiants les calculs à faire si ceux-ci différent d'un type de contentieux à l'autre. Ceci afin de gérer dynamiquement l'affichage et les traitements, ne pas écrire du code illisible avec des dizaines de IF, et pouvoir éventuellement par la suite rajouter un type de contentieux sans toucher au code. Si les traitements ne différent pas trop (le "pas trop" est très subjectif...) d'un type à l'autre c'est faisable. Bon courage.
	00

04/04/2006, 11h30	#3
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	Est-il possible qu'un modérateur déplace mon sujet qui n'a plus sa place dans la section Access, mais plutot dans la section My Sql ou SGBD. Merci au modérateur. Bonjour, Merci pour la réponse ( que j'avais deja lu ). J'ai du temps pour me remettre sur la question, j'ai donc utiliser le logiciel DB designer pour ensuite crée ma base sous MySql. Voila un premier jet, pouvez vous me conseillez, m'aiguillez.
	00

04/04/2006, 15h32	#5
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	Alors, j'essaye comme je peux Voila un premier jet pour un schéma entité-association :
	00

04/04/2006, 18h26	#6
beaba Invité de passage Inscription : avril 2006 Messages : 2 Détails du profil Informations forums : Inscription : avril 2006 Messages : 2 Points : 1 Points : 1	Shellai, mets toujours un Identifiant dans les attributs de tes entités. Sinon, tu as reçu un super conseil de maximilian : fignole ton MCD, passe au modèle relationnel et ensuite tu as directement la structure de tes tables et tu ne peux pas te tromper. Bon courage Béaba
	00

10/04/2006, 16h36	#7
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	( je débute, donc je suis pas encore au point au niveau des méthodes à suivre, merci en tout cas pour vos conseils méthodologique ) J'ai donc mis des identifiants :
	00

11/04/2006, 12h15	#9
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	Hello, Oui en effet désolé c'est loin d'etre explicite pour vous. Donc, date, montant, dette.. reviennent constamment, car comme tu la deviné il faut gardé un historique. Pour donner un exemple, la liste des contentieux voir 1er document : _ Demande d'engagement de procédure _ Assignation _ ... Ses evenements arrivent de facon chronologique, l'un aprés l'autre et on doit garder à chaque évenement la date, le montant de la dette à l'instant t, etc. Mais il y'a des exceptions, des évenement dont les informations puissent etre saisie ultérieurement, de facon graphique il faudrait une case grisée qui puisse etre saisisable plus tard.
	00

12/07/2006, 17h05	#11
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	Bonjour, J'ai du laisser le projet de coté pendant quelque mois, j'ai maintenant le temps de m'y remettre ( enfin je dois surtout le bouclé pour Septembre...) mais bref. Merci pour ton aide Maximilian, j'espere que tu aura un peu de temps à me consacré à nouveau. Donc, j'ai suivi les liens que tu as donnée expliquant le principe d'héritage, je pense l'avoir compris. Cela dit, ce que je ne comprend pas c'est pourquoi je devrais mettre dans la table evenement à la fois "date, montant dette,..." et aussi le type d'evenement. D'aprés ce qu'il me semble avoir compris de la mécanique d'héritage.. il ne faudrait pas plutot mettre le type d'evenement ( par exemple Assignation ou Audience ou Jugement) dans la table Contentieux qui sera fille de la table mere Evenements. ?
	00

31/07/2006, 15h39	#12
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	up, besoin d'une petite aide pour les tables d'héritage
	00

07/08/2006, 00h33	#13
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	C'est encore moi... Que pensez vous de cela, j'ai utiliser la table Evenement comme table mere de la table fille Contentieux. J'ai utilisé le principe d'héritage de sorte à pouvoir repeter à chaque contentieux les evenements date, montant dette.. Je n'ai biensur pas remplis complétement mes tables. J'admet, je patauge un peu pour ma 1ere bdd...
	00

08/08/2006, 16h15	#15
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	Hum, je me rend compte à chaque fois à quel point je n'ai pas encore la logique.. base de données.. bon ca viendra! Bon, je vais pas faire de schémas inutiles à chaque fois donc j'ai pondu ça: Client [#numero_client; Foyer; Nom; Prenom; Lot ] Contentieux[#ID_conten; numero_client; Evenement[ID_conten; Demande_engagement; Assignation; Audience; ...; Classement_Dossier] Date[ID_conten; date; date_edition; date_demande; date_envoie] Montant[ID_conten; montant_dette; montant_indeminisation] Honoraires [#ID_honoraire; tiers, date_paiement, montant] d'aprés ce que tu m'as dit, j'ai essayé de repensé la chose en créant les tables (sur le papier, hein) date et montant qui sont des tables filles de la table evenement. Et j'ai crée la table honoraire, qui n'a pas besoin d'hérité de la table evenement. Tu peux me dire ce que tu en penses
	00

10/08/2006, 14h45	#17
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	Ouais c'est plus clair merci, c'est pas que c'était pas clair avant, juste que j'avais mal compris la facon de procéder ( rassembler les entités identiques ) Donc, ca me donnerait ça, si j'ai bien compris : Client(#numero_client, Foyer, Nom, Prenom, Lot) Contentieux(#ID_conten; numero_client) (J'ai un point d'ombre concernant l'utilité/fonction de cette table.. et comment la remplir) Evenement (#id_evenement, date, montant_dette, type_evenement) Demande_eng_proc (id_evenement, transmission, traitement) Assignation (id_evenement, reception_avocat) Recours_comp (id_evenement, montant_indemnisation) Recours_contentieux (id_evenement, montant_indemnisation) Indemnisation (id_evenement, montant_indemnisation) Imputation_art700 (id_evenement, references) Autres_imputations (id_evenement, references) Concernant la partie que j'ai mis en marron, donc comme ton exemple du contact, là ce qui permettra de savoir si il faut aller dans telle ou telle table fille ca sera l'attribu "type_evenement" de la table mere Evenement...? Mais dans le cas où c'est un evenement comme Audience qui ne fait pas appel à une table fille, comment on le gere...? on va simplement remplir le champs type_evenement qui ne sera donc pas le nom d'une des tables filles.. et il saura qu'il a pas besoin "d'aller plus loin" ? Enfin j'imagine que ça, je devrais le gerer lors de la programmation sql...? En tout cas merci pour tes explications, j'apprend beaucoup, j'aurai pas eu cette patience avec un boulet comme moi Edit: ah oui, je voulais également te demander si il n'était donc pas possible de rassembler les tables filles suivantes : Recours_comp (id_evenement, montant_indemnisation) Recours_contentieux (id_evenement, montant_indemnisation) Indemnisation (id_evenement, montant_indemnisation) & Imputation_art700 (id_evenement, references) Autres_imputations (id_evenement, references) Ne pourrais-je pas y ajouter un attribut comme type_evenement, simplement pour préciser si c'est par exemple un recours complémentaire ou un recour contentieux ? Donc : Indemnisation ( id_evenement, montant_indemnisation, type_evenement2) & Reference( id_evenement, references, types_evenement3)
	00

10/08/2006, 18h00	#19
Shellai-93 Invité régulier Inscription : février 2006 Messages : 22 Détails du profil Informations forums : Inscription : février 2006 Messages : 22 Points : 7 Points : 7	Ok pour la table contentieux, c'est capish. Concernant le 2nd niveau d'héritage, dans ce cas je vais laisser tel quel alors, j'ai pas spécialement d'interet à regrouper les tables finalement, et si ca simplifie les requetes, on va laisser comme ça En reprennant tout du début, j'en arrive donc à cela, niveau MCD : En fait, j'ai un gros doute sur les cardinalités... _ De client à contentieux : 1,n car un client peut avoir 1 ou plusieurs contentieux en cours _ De contentieux à client : 1,1 car un contentieux ne peux etre identifié qu'a un seul client...? _ De contentieux à Evenement : 1,n car d'un contentieux peux resulter plusieurs evenements _ D'Evenement à contentieux : 1,n, car un evenement peut etre applicable à different contentieux
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email