envoie des données avec la methode get
Bonjour!
Je suis en train de créer une application pour gérer les activités de l'église catholique cas d'un diocèse. En fait, cette application doit gérer le sacrement(baptême, communion, confirmation, mariage, etc.) en principe, pour chaque enregistrement d'un sacrement, je dois l'attribuer par un numéro de registre qui est différent de la clé primaire de ma table. Ceci me complique un peu. Voici les tables que j'ai déjà créé:
tableSacrement(idsacrement,libelle)
tableParoisse(idP,description,#idDiocesse)
TableCandidat(CodeCandidat,nom,postnom)
Tableconcerner(idConcerner, #idsacrement,#idP, #CodeCandidat)
TableMariage(idMariage,#CodeCandidat,#idP,condjoint)
Le candidat est une personne qui doit recevoir un sacrement, étant donné que nous avons plusieurs paroisses enregistrées dans notre base de données, le principe exige que chaque paroisse ait la possibilité d'enregistrer le sacrement mais nous devons avoir un numéro de registre pour identifier le sacrement enregistré dans chaque paroisse. J'ai créé en effet une autre table que j'ai appelée tableCompteur(idCompteur,idConcerner,idMariage,numero).
Mon souci est le suivant: j'ai créé la requête ci-après :
$var = mysql_query("select * tableCompteur where numero = last_insert_id(numero )");
if(mysql_num_rows($var)>0)
{
while($ligne = mysql_fetch_array($var))
{
$numero = $ligne['numero'] + 1;
}
}
else
{
$numero = 1;
}
Ces instructions marchent très bien sauf la difficulté que j'ai maintenant réside au niveau du numéro, pourquoi? À tout moment quand le numéro est incrémenté, il ne fait allusion à la paroisse et pourtant je veux que chaque sacrement dans une paroisse ait un numéro commençant par 1 mais quand il par exemple 1 sur la ligne numéro, la ligne paroisse a par valeur A, il y a la possibilité que la ligne paroisse ait déjà une valeur B, hors numéro = 1 et il sera incrémenté quand il y aura un nouvel enregistrement, moi je veux:
- quand paroisse = A, numero = 1 à l'enregistrement
- quand paroisse = A, numero = 2 à l'enregistrement
mais
- quand paroisse = B, numero = 1 à l'enregistrement
et ainsi de suite. Voilà la première difficulté que j'ai.
La deuxième difficulté, j'ai une page que j'appelle AddConcernant.php, celle-ci me permet d'enregistrer les informations de candidat et le sacrement qu'il veut recevoir. Quand je valide mes instructions, j'ai fait en sorte que je puisse voir un petit tableau dans lequel il y un bouton nommé numéroter après enregistrement des informations, si je clique sur ce bouton, je suis directement redirigé sur une page qu'on appelle numero.php avec la méthode GET, cette page me permet d'attribuer le numéro au sacrement que je venais d'enregistrer. voici mon script:
<tr>
<td>
<a href='numero.php?idSacrement=$a'> <button type='submit'>NUMEROTER</button></a>
</td>
</tr>
cette instruction se trouve sur la page AddConcernant.php,
<?php
$code = $_GET['idSacrement'];
echo $code;
?>
Ces dernières se trouvent à la page numero.php, le problème posé est que la variable $code ne s'affiche et comme erreur envoyée, idSacrement n'est pas déclaré. Merci de pouvoir me venir en aide.
Réponses apportées à cette discussion
Salut Giresse,
fonctionnellement, je n'ai pas compris grand chose.
Je ne saisis surtout pas bien la pertinence de deux tables :
- la table
TableMariage: elle est redondante avecTableSacrementdans la mesure où un mariage est également un sacrement, créer une table indépendante ne s'explique donc pas ici; - la table
TableCompteur: à quoi sert-elle au juste ?
Un des éléments que je redis régulièrement, c'est que si la base de données est bancale, l'application finira tôt ou tard par être tout aussi bancale.
Il convient donc de commencer par bien délimiter le périmètre fonctionnel.
Autre point, l'utilisation dans une requête de la fonction last_insert_id m'apparait hasardeuse : on ne l'emploie d'ordinaire qu'à la suite d'une insertion pour récupérer la clé primaire. Si c'est pour récupérer le dernier numéro, il serait préférable d'utiliser MAX(numero), éventuellement en ajoutant une clause GROUP BY si nécessaire.
Enfin, ce serait bien de relire tranquillement avant de poster, certaines phrases n'ont absolument aucun sens.
Je suggère donc de commencer par redéfinir l'aspect fonctionnel, on pourra alors correctement définir les tables. Ensuite on verra pour le code et la manière de traiter les données.
Bonjour Cyrano!
Avant de donner un éclaircicement, voici d'abord toutes les tables de mon projet:
create table candidat(
CodeCandidat int(11) auto_increment not null,
Nom varchar(100) not null,
Postnom varchar(100) not null,
Prenom varchar(100) not null,
DateNaiss date not null,
lieuNaiss varchar(100) not null,
NomPere varchar(100) not null,
NomMere varchar(100) not null,
Sexe varchar(100) not null,
Photo varchar(100) not null,
Telephone varchar(25) not null,
CodCevb int(11) not null,
primary key (CodeCandidat)
);
create table tuteur (
IdTuteur int auto_increment not null,
NomTuteur varchar(100) not null,
PostnomTuteur varchar(100) not null,
PrenomTuteur varchar(100) not null,
SexeTuteur varchar(100) not null,
primary key (IdTuteur)
);
create table Ministre (
CodeMinistre int auto_increment not null,
NomMinistre varchar(100) not null,
PostnomMinistre varchar(100) not null,
PrenomMinistre varchar(100) not null,
CategorieMinistre varchar(100) not null,
primary key (CodeMinistre)
);
create table sacrement (
IdSacrement int auto_increment not null,
Libelle varchar(100) not null,
primary key (IdSacrement)
);
create table Concerner (
IdConcerner int auto_increment not null,
dateCeremonie date,
IdSacrement int(11) not null,
IdParoisse int(11) not null,
CodeCandidat int(11) not null,
CodeMinistre int(11) not null,
IdTuteur int(11) not null,
primary key (IdConcerner)
);
create table Paroisse (
IdParoisse int(11) not null,
Description varchar(100) not null,
dateImplantation date not null,
lieuImplantation varchar(100) not null,
CodDiocese varchar(10) not null,
primary key (IdParoisse)
);
create table partenaire (
Idpartenaire int not null,
NomPartenaire varchar(100) not null,
PostnomPartenaire varchar(100) not null,
prenomPartenaire varchar(100) not null,
sexePartenaire varchar(5) not null,
dispense varchar(100) not null,
primary key (Idpartenaire)
);
create table CompteurMariage (
IdCompteur int not null,
Idmariage int not null,
NumeroMariage varchar(100) not null,
primary key (IdCompteur)
);
create table CompteurSacrement (
IdCompteurSacre int not null,
IdConcernerint int not null,
NumeroConcerner varchar(100) not null,
primary key (IdCompteurSacre)
);
create table mariage (
Idmariage int not null,
IdSacrement int(11) not null,
IdParoisse int(11) not null,
CodeCandidat int(11) not null,
Idpartenaire int not null,
CodeMinistre int(11) not null,
IdTuteur int(11) not null,
primary key (Idmariage)
);
create table CEVB (
CodCevb int(10) not null,
designCevb varchar(100) not null,
DateCevb date not null,
LieuCevb varchar(100) not null,
CodChapelle varchar(10) not null,
primary key (CodCevb)
);
create table chapelle (
CodChapelle varchar(10) not null,
designChapelle varchar(100) not null,
DateChapelle date not null,
LieuChapelle varchar(100) not null,
CodSecteur varchar(10) not null,
primary key (CodChapelle)
);
create table secteur (
CodSecteur varchar(10) not null,
designSecteur varchar(100) not null,
DateSecteur date not null,
LieuChapelle varchar(100) not null,
IdParoisse int(11) not null,
primary key (CodSecteur)
);
create table diocese (
CodDiocese varchar(10) not null,
designDiocese varchar(100) not null,
DateErection date not null,
primary key (CodDiocese)
);
alter table secteur add foreign key (IdParoisse) references Paroisse (IdParoisse);
alter table chapelle add foreign key (CodSecteur) references secteur (CodSecteur);
alter table CEVB add foreign key (CodChapelle) references chapelle (CodChapelle);
alter table candidat add foreign key (CodCevb) references CEVB (CodCevb);
alter table Paroisse add foreign key (CodDiocese) references diocese (CodDioces);
Ma préoccupation est d'avoir état de sortie que je vais appeler le registre, il peut être un registre du sacrement de mariage, registre du sacrement de baptême, registre du sacrement de communion, registre sacrement de confirmation, etc. Alors pour chaque registre, nous devons avoir un numéro identifie chaque sacrement des différents dates et différents candidats.
Alors votre préoccupation était de savoir pourquoi j'ai utilisé la table mariage pendant que mariage est également un sacrement?
Je suis un candidat, je dois recevoir un sacrement de mariage, ma fiancée ou mon fiancé peut ou n'est pas fréquenté l'église catholique, et la logique impose que, pour avoir un sacrement de mariage, le candidat doit être catholique, il doit déjà avoir réussi les sacrements de baptême, communion et de confirmation.
Alors, pour le sacrement de mariage, il s'agit de deux personnes dont l'une est le candidat et fréquente l'église catholique, l'autre peut être catholique ou non mais elle suit la volonté de son ou sa condjoint(e) de recevoir le sacrement de mariage dans l'église catholique.
J'aimerai alors avoir votre idée par à ces deux tables notamment la table mariage et la table sacrement, qu'est-ce que vous me proposez si je ne devais pas utiliser la table mariage qui doit m'enregistrer les informations du candidat et de la personne avec qui il compte se marier?
Bonjour,
il reste encore des zones d'ombre dans les explications, mais il y a déjà largement de quoi faire avec la base de données. Donc pour l'immédiat, on va s'en tenir là. Et mon avis concernant cette base est qu'on doit la revoir complètement en y ajoutant en outre des conventions techniques, j'y reviendrai.
Je vais donc commencer par essayer de reformuler l'idée générale qu'il faudra me confirmer ou corriger si nécessaire avant d'aller plus loin.
Description fonctionnelle
- Le projet consiste à enregistrer les sacrements prononcés dans un diocèse.
- On pourra avoir plusieurs diocèses;
- Pour chaque diocèse, il peut y avoir 1 à n paroisses;
- Dans une paroisse, nous pourrons avoir un ou plusieurs lieux de culte, chapelle, église, cathédrale, etc..
- Nous avons différents interlocuteurs :
- les ministres du culte appartenant à une hiérarchie au sein de laquelle ils ont un rang : prêtre, diacre, évêque etc..;
- les paroissiens appelés à recevoir lesdits sacrements ou encore ceux devant participer sans recevoir eux-même le sacrement, par exemple les parents, parrain et marraine pour un baptême, ou encore les témoins d'un mariage;
- Nous avons différents sacrements, sept si je ne fais pas erreur :
- Les trois sacrements de l’initiation chrétienne : Baptême, Eucharistie et Confirmation;
- Les sacrements de guérison : Réconciliation et Onction des malades;
- Les sacrements de l’engagement : L’Ordre et le Mariage;
- chaque sacrement dispensé sera assorti d'un numéro de registre unique pour chaque paroisse (la formulation n'est pas vraiment claire, il faudrait être plus précis sur ce point)
- Nous avons enfin les cérémonies auxquelles sont liées les interlocuteurs, les sacrements dispensés, les lieu et les dates.
Analyse technique
Du descriptif précédent, nous allons construire un dictionnaire de données. Ce dictionnaire va déterminer chaque mot clé. À partir de là, la première étape va consister à faire un premier ménage en supprimant les redondances, les synonymes par exemples. Ensuite, on va pouvoir construire le modèle conceptuel de données : certains de ces mot-clés deviendront des entités indépendants, d'autres seront des propriétés de ces entités. Enfin, on va établir les relations existant entre certaines entités ainsi que ce qu'on nomme les cardinalités, ce qui n'a absolument rien à voir avec les cardinaux de l'église, ça désigne la multiplicité des relations et leur sens entre les entités.
Par exemple, nous pouvons relever les mots diocèse et paroisse : on établit les cardinalités en notant qu'un diocèse correspond à 1 à n paroisse, et à l'inverse qu'une paroisse appartient à 1 et 1 seul diocèse.
Un autre point important, c'est que certaines relations peuvent être multiples dans les deux sens : nous aurons donc entre les deux une relation qui pourra en outre avoir des propriétés propres.
À votre tour
Je suggère de reprendre sur la base qui précède : complétez et corrigez si besoin est la description fonctionnelle en détaillant autant que possible de telle sorte que nous retrouvions tous les mots-clés dont nous aurons besoin par la suite. Par exemple, j'ai noté une table « tuteur » : je ne sais pas vraiment à quoi ça correspond, il conviendrait d'expliquer ce que c'est dans la description fonctionnelle.
Pour la partie codage, numérotation etc... on s'en occupera après : il est indispensable que ce socle soit d'abord établi de façon solide et durable.
Bonjour Cyrano!
Concernant le point 7: chaque sacrement dispensé sera assorti d'un numéro de registre unique pour chaque paroisse, mais ce numéro ne doit pas être pris pour l'identifiant de la table autrement dit la clé primaire. Alors c'est là où provient mon problème.
Pour la table tuteur, je voulais que cette dernière enregistre les informations sur les temoins des candidats (parrain ou marraine pour le sacrement de baptême et les temoins de mariage pour le sacrement de mariage). Toutesfois, si le mot tuteur semble un peu vague et ne vous convainc pas, j'aimerai avoir une idée de votre part, et cela va de pair pour d'autres tables.
La table CEVB, elle va nous enregistrer les informations sur un groupe auquel un candidat peut appartenir, d'où ce groupe sera répéré dans une chapelle.
Comme vous m'aviez dit que la partie codage interviendra plus tard, la table CompteurMariage devra m'enregistrer les informations de chaque mariage célébré pour chaque paroisse en lui dotant d'un numéro que nous allons appeler le numéro de registre.
Ma préoccupation revient à la table mariage, qu'est-ce que vous me proposez de faire?
Si vous dites qu'il existe 7 sacrements, serait-il important que j'établisse 7 tables pour identifier chaque sacrement que de garder une seule table capable de nous enregistrer les 7 sacrements?
Bonjour,
non, pas sept tables, une seule table sacrements répondra parfaitement au besoin. Mais il ne faut pas mettre la charrue avant les bœufs. Si je dis ça, c'est parce qu'il ne faut pas à ce stade penser en terme de tables ou de relations dans l'immédiat, ça interviendra dans l'étape suivante. Pour l'instant, il est très important de bien définir les détails fonctionnels et d'isoler les mots-clés et constituer ce qu'on appelle un dictionnaire de données à partir duquel on pourra définir quelles tables on va devoir mettre en place. Et même là, on ne parlera même pas de table, mais d'entités et de propriétés.
Prenons l'exemple de définition fonctionnelle telle que je l'ai formulée précédemment, on va trouver les mots clés suivants :
- diocèse;
- paroisse;
- lieu-de-culte;
- chapelle;
- église;
- cathédrale;
- ministre;
- paroissien;
- etc..
Pour distinguer ce qui est une entité de ce qui est une propriété d'une de ces entités, il faut s'interroger sur le lien qui peut exister entre deux mots. par exemple nous avons lieu-de-culte et église : un lieu de culte n'est pas forcément une église puisque ça peut être une chapelle ou une cathédrale, mais une église est un lieu de culte, comme le sont également les chapelles et les cathédrales. Donc se dégage un terme qui n'apparaît pas forcément dans le dictionnaire de données, c'est le type de lieu de culte, donc ici type sera une propriété de l'entité lieu-de-culte
Est-ce que cette explication rend l'approche plus claire ?
Bonjour!
D'après vos explications, ça se comprend mais j'aime plus la pratique. S'il vous plait, ne le prenait pas mal, veuillez le faire d'une façon pratique pour les entités dont vous aimeriez apporter des modifications puisque vos idées semblent les meilleures.
voici par exemple, je considérais tout ce qui est du lieu-de-culte, de cathédrale comme étant une paroisse. Et d'après ce que vous venez de m'expliquer ci-haut, ce que j'étais dans l'embarras. Si possible, veuillez m'envoyer un fichier sur mon adresse mail:giressenkj@gmail.com, cela me permettra de bien comprendre.
Bonjour Giresse,
Vous dite « ça se comprend mais j'aime plus la pratique » : et que croyez-vous donc que je vous explique ? Ce n'est pas juste théorique, c'est complètement pratique.
Par ailleurs, je rappelle que nous sommes ici sur un forum public où ceux qui savent partagent avec ceux qui apprennent. Ça n'inclut pas le support privé. Je ne l'exclue pas pour autant, mais pas gratis.
Comprenez que le problème que l'un rencontre aujourd'hui, d'autre le rencontreront demain, or l'objectif du forum est précisément de laisser une trace à l'intention de ces derniers. Donc si on passe par des échanges privés, ils ne trouveront pas le chemin vers la solution et je devrai accessoirement reprendre et recommencer.
Autre point : vous connaissez sûrement ce proverbe chinois qui dit « Si tu donnes un poisson à un homme, il se nourrira une journée, si tu lui enseignes la pêche, il se nourrira toute sa vie »
Là, en me demandant un fichier par message privé, vous me demandez le poisson pendant que je tente de vous enseigner la pêche. Je n'y vois pas d'objection, mais dans ce cas, ça s'appelle de l'assistance à maitrise d’œuvre et je peux parfaitement le faire, mais il va vous falloir prévoir un budget pour ça parce que ce sera assorti d'une facture.
Donc, comme j'ai déjà une vague idée de la réponse, je vais à priori reprendre le cours des choses là où nous l'avions laissé : il faut construire un dictionnaire de données pour élaborer le modèle conceptuel de données. Ce n'est, encore une fois, pas de la théorie, je suis tout ce qu'il y a de plus sérieux. Et ce n,est pas moi qui vais construire ça, c'est votre application, vous avez la maitrise de votre sujet, donc c'est vous qui allez construire ce modèle, même si je dois vous indiquer le chemin. Ce que j'essaye de vous montrer, c'est une méthode de travail et de raisonnement pour que l'application que vous allez construire soit solide, durable et puisse éventuellement évoluer au fil du temps lorsque vous voudrez y ajouter des fonctionnalités.
Pour comprendre le concept Entité/Association, il y a un tuto que j'avais publié sur PHPFrance il y a presque 10 ans et qui est toujours valable, un tuto sur les jointures : c'est quelque chose de très basique pour ne pas perdre le débutant dans des abstractions trop compliquées.
Donc reprenez ce qu'on a déjà vu plus haut, analysez, reprenez votre problème et suivez les suggestions que j'ai formulées, et là on va avancer ;-)
Bonjour Cyrano!
Je comprend.
D'après ce que vous demandez de faire c'est d'établir un dictionnaire des données. Voici comment j'ai appris à établir un dictionnaire des données, c'est loin d'être meilleur, apporte-moi de correction si possible:
N° ENTITE ATTRIBUT TYPE IDENTIFIANT LONGUEUR
1 Candidat codCand int # X(5)
NomCand varchar X(100)
Postnom varchar X(100)
2 Paroisse IdParoisse int # X(5)
libelle Varchar X(100)
3 Diocese idDiocese int # X(5)
nomDiocese varchar X(100)
4 Secteur idSecteur int # X(5)
nomSecteur varchar # X(100)
5 chapelle idChapelle int # X(5)
nomChapelle varchar X(100)
6 Cevb idCevb int # X(5)
nomCevb varchar X(100)
7 Recevoir idRecevoir int # X(5)
dateRecevoir date
idParoisse int X(5)
idSacrement int X(5)
CodCand int X(5)
8 Tuteur idTuteur int # X(5)
nomTuteur varchar X(100)
9 Ministre idMinistre int # X(5)
nomMinistre varchar X(100)
categorie varchar X(100)
N° ENTITE ATTRIBUT TYPE IDENTIFIANT LONGUEUR
1 Candidat codCand INT # X(5)
NomCand VARCHAR X(100)
Postnom VARCHAR X(100)
2 Paroisse IdParoisse INT # X(5)
libelle VARCHAR X(100)
3 Diocese idDiocese INT # X(5)
nomDiocese VARCHAR X(100)
4 Secteur idSecteur INT # X(5)
nomSecteur VARCHAR X(100)
5 chapelle idChapelle INT # X(5)
nomChapelle VARCHAR X(100)
6 Cevb idCevb INT # X(5)
nomCevb VARCHAR X(100)
7 Tuteur idTuteur INT # X(5)
nomTuteur VARCHAR X(100)
8 Ministre idMinistre INT # X(5)
nomMinistre VARCHAR X(100)
categorie VARCHAR X(100)
9 Recevoire idRecevoir INT # X(5)
dateRecevoir DATE X(5)
idParoisse INT X(5)
IdSacrement INT X(5)
codCand INT X(5)
idTuteur INT X(5)
Salut,
c'est pas ça du tout.
Le dictionnaire de données, c'est une liste des mots clés identifiés dans la définition fonctionnelle de l'application. On ne s'occupe à ce stade pas du tout de les numéroter ou encore de définir leur type ou les relations existant entre les uns et les autres, on fait une liste en vrac de tout ce qui semble décrire un élément qu'on va retrouver régulièrement dans le fonctionnement de l'ensemble. J'ai donné un exemple plus haut en indiquant :
« Prenons l'exemple de définition fonctionnelle telle que je l'ai formulée précédemment, on va trouver les mots clés suivants :
- diocèse;
- paroisse;
- lieu-de-culte;
- chapelle;
- église;
- cathédrale;
- ministre;
- paroissien;
- etc..
»
Là, ce que vous montrez n'est pas un dictionnaire de données mais un début de modèle de données, il y a des mots que je ne comprends pas comme « cevb » ou d'autres qui, en première lecture, ne signifient rien comme « CodeCand ». En pratique, je sais et que ça doit se traduire par « Code Candidat », mais j'ignore à quoi ça correspond dans la mesure où ce n'est pas clairement établi dans la définition fonctionnelle, laquelle décrit l'application en détails.
Pourquoi j'insiste si lourdement sur ce dictionnaire ?
Tout simplement parce que c'est le socle indispensable de l'application. Tout le reste du développement dépend de sa construction correcte. Si on monte une base bancale, tôt ou tard l'application sera bancale et au fil du temps de moins en moins réparable sans des travaux majeurs, lourds, longs et coûteux. Il faut essayer de réfréner cette envie pressante de plonger dans le code : le développement d'une application bien faite, c'est entre 50 et 70% d'analyse, de telle sorte que la partie codage, sans devenir pour autant triviale,devient infiniment moins compliquée. Si je fais une analogie avec un exemple qui soit parlant, l'exemple de cette application m'en fournit un tout trouvé : Une première communion, c'est d'abord un an ou deux de catéchisme pour aboutir à une cérémonie qui dure à peine une heure. Pour le catéchumène, c'est parfois long et incompréhensible, pourquoi tant de discours et d'histoires pour pouvoir communier ? Parce que la communion, ce n'est pas juste manger un bout de pain azyme, ça va bien au-delà de ça et le catéchisme va mettre en place tous les éléments de la compréhension de ce qu'est la communion. Vouloir aller plus vite reviendrait à vouloir bâtir sur du sable au lieu de creuser jusqu'au roc pour poser de solides fondations qui tiendront longtemps et garderont la maison debout pendant des années au lieu de s'effondrer au premier coup de vent un peu violent.
Je suis bien conscient par ailleurs que ça peut paraitre long et rébarbatif. Mais il faut garder l'objectif en tête pour se motiver.
Nouvel exemple miniature, construisons un annuaire :
Description fonctionnelle :
Répertoire
L'application permet de répertorier une liste de mes relations personnelles. Elle permettra d'enregistrer de nouveaux contacts, de les modifier voire de les supprimer. Chaque contact sera constitué d'un nom, d'un prénom et éventuellement d'un ou plusieurs numéros de téléphones selon leur types, qu'il s'agisse du numéro du domicile du contact, d'un numéro de téléphone mobile, du numéro de fax ou autre qui devra être précisé.
Dictionnaire de données :
là, on relit la définition fonctionnelle et qu'on surligne certains mots, et on aboutit à la liste suivante :
- répertoire
- relations personnelles
- contacts
- civilité
- nom
- prénom
- numéro de téléphone
- type (téléphones)
- domicile
- mobile
- fax
Qu'est-ce qu'on peut remarquer dans cette liste ?
D'abord qu'on y voit aucun identifiant particulier, ça, on verra ça dans la construction du modèle de données.
Ensuite, on remarque dans le texte que ce qui concerne les téléphones est précédé du mot « éventuellement », ce qui implique qu'on pourra avoir un contact qui ne possède aucun numéro de téléphone.
Donc là, on peut identifier deux entités : « Contact » et « Téléphone ». Les autres mots clés trouvés sont des propriété de l'une ou l'autre de ces entités.
On s'occupera du modèle de données lorsque cette première liste sera établie.
Bonjour Cyrano !
Je ne sais pas si j’ai fait un effort de comprendre ce que vous m’aviez demandé de faire mais au moins je voulais essayer en établissant ce qui suit :
La description fonctionnelle
- Le projet consiste à enregistrer un le sacrement prononcé dans un diocèse.
- On pourra avoir plusieurs diocèses. Dans chaque diocèse, il doit y avoir une ou plusieurs paroisses
- Dans une paroisse, nous pourrons avoir un ou plusieurs secteurs. Un secteur est un lieu de culte implanté dans un quartier pour rassembler tous les paroissiens de ce quartier.
- Chaque secteur peut avoir une ou plusieurs chapelles. une chapelle est un lieu de culte également mais implanté dans une avenue pour rassembler également les paroissiens de cette avenue.
- Dans une chapelle, nous pourrons identifier des groupes notamment le groupe de chorale, un groupe des personnes pour l’apostolat, un groupe des personnes pour la propreté de la chapelle, tous ces groupes sont appelés cevb. Donc, dans une chapelle, on peut avoir un ou plusieurs cevb.
- Pour chaque cevb, on sait retrouver les paroissiens qui ont déjà reçus ou non le sacrement notamment de baptême, de communion, de confirmation, de mariage, etc.
- Un sacrement est un acte religieux institué pour la sanctification des âmes. Le sacrement se succède c.à.d. on ne peut pas recevoir le sacrement de mariage avant le sacrement de baptême, ainsi donc, le premier est celui de baptême suivi du sacrement de communion, ensuite vient le sacrement de confirmation et le reste le sacrement de mariage, le sacrement de décès, etc.
- Un candidat est un paroissien qui veut recevoir un sacrement quelconque, il doit être identifié dans une chapelle. Il est obligé de recevoir le sacrement par étape, c.à.d. il ne doit pas recevoir le sacrement de mariage avant le sacrement de baptême. Un candidat doit avoir un nom, un post nom, prénom, une date de naissance, un témoin appelé encore parrain (marraine) une qu’il accompagne, etc.
- Un témoin est une personne que nous avons définie comme une personne qui accompagne un candidat, il est supposé avoir au moins tous les sacrement à l’exception de celui de décès.
- Le ministre sont des personnes qui appartiennent à une hiérarchie au sein de laquelle ils ont un rang, c’est ainsi que nous pouvons les identifier par catégorie de prête, diacre, évêque, etc. Ils ont le rôle de célébrer la cérémonie de sacrement reçu par un candidat.
Ben voilà, on commence à avancer : nous avons maintenant une base de travail, cette description va permettre de définir les fonctionnalité de l'application.
Maintenant, il faut relire cette description en surlignant les mots-clés, ce qui est une donnée qui devra être traitée, éventuellement enregistrée/modifiée/supprimée. Et ensuite, on fera le tour de cette liste pour en retirer d'une part les doublons et d'autre part ce qui est ce qu'on appelle « du bruit ».
Enfin, on pourra construire le modèle conceptuel de données en différenciant dans la liste finale ce qui est une entité et ce qui est la propriété d'une entité donnée.
Petite note au passage : le sacrement de décès n'existe pas, j'ai donné dans une réponse précédente la liste des sacrements existants, et l'extrême onction n'est pas dans cette liste.
Enfin, il me reste malgré tout une question : comprenez-vous bien la démarche que je vous explique, au moins pour le moment ? Sinon, il faut me dire ce qui n'est pas clair et je tâcherai de reformuler.
Bonjour Cyrano!
Bon, j'essaye de comprendre parce que vous avez dit précédement que c'est le socle indispensable de l'application, et tout le reste du développement dépend de sa construction correcte.
Merci pour cette remarque, j'en tiendrai compte. Je pense que la liste des sacrements que vous aviez donné dans la réponse précédente est la suivante:
- Les trois sacrements de l’initiation chrétienne : Baptême, Eucharistie et Confirmation;
- Les sacrements de guérison : Réconciliation et Onction des malades;
- Les sacrements de l’engagement : L’Ordre et le Mariage;
Pour le sacrement de guérison, je ne sais si un paroissien qui n'a jamais reçu le le sacrement de l'initiation chrétienne peut aussi le recevoir.
J'ai relu la description et je pense que les mots clés sont les suivants:
1. Sacrements (le sacrement de l’initiation chrétienne, Les sacrements de guérison ainsi que les sacrements de l’engagement)
2. Diocese
3. Paroisse
4. Secteur
5. Quartier
6. Avenue
7. Chapelle
8. Cevb
9. paroissien
10. Candidat
11. Temoin
12. Ministre
Bonjour,
je compte pour ma part bien davantage de mots-clés. Si je reprends la descriptions fonctionnelle vue plus tôt, j'obtiens cette liste-ci :
- sacrement
- diocèse
- paroisses
- secteurs
- lieu de culte
- quartier
- paroissiens
- chapelles
- groupes
- chorale
- apostolat
- propreté de la chapelle
- cevb
- baptême
- communion
- confirmation
- mariage
- nom
- post nom
- prénom
- date de naissance
- témoin
- parrain
- marraine
- candidat
- ministre
- hiérarchie
- prête
- diacre
- évêque
En établissant cette liste, on peut se rendre compte qu'il peut même en manquer (exemple, ordre chronologique des sacrements, ou encore si on se rend compte qu'on a affaire à des interlocuteurs lorsqu'on parle de participant, de ministre ou de candidat), ou encore que certains mériteraient une traduction (par exemple « cevb », je présume que c'est un sigle mais j'ignore ce qu'il signifie)
Pour d'autres, la liste est largement incomplète : pour les lieux de culte par exemple, il n'est question que de chapelles, mais on peut avoir aussi des églises, des cathédrales, des basiliques.
Un autre détail m'échappe concernant le caractère obligatoire de certains sacrements par rapport à d'autres : il faudrait vérifier ça dans le Droit Canon ou encore demander à votre curé qui doit savoir ça de façon plus formelle. La description indique (sommairement) que les sacrements de guérison ou d'engagements requièrent d'avoir obtenu au préalable les sacrements d'initiation.
Le tri de cette liste
Maintenant que fait-on avec cette liste ? On va en extraire d'une part ce qu'on appellera des entités et définir pour les autres de quelle entité ils sont les propriétés.
Exemple : je vais utiliser le mot que j'ai ajouté dans les observations après la liste : interlocuteur. Cette entité comporte certaines propriétés que je vais également extraire de cette liste :
- nom
- post nom (ça aussi ce serait bien de le traduire parce que je n'ai aucune idée de ce à quoi ça correspond)
- prénom
- date de naissance
Voyons avec un autre mot, hiérarchie : elle indique les rangs que peuvent occuper les ministres.
J'ai relevé à la suite de hiérarchie trois rangs existants à savoir prêtre, diacre et évêque. On pourrait d'ailleurs en ajouter d'autres, mais en réalité ce serait inutile : là, nous avons ce que je nommais dans une réponse précédente de la pollution parce que ce ne sont ni des entités ni des propriétés de hiérarchie, ce sont des valeurs possibles. Donc on peut rayer ces mots. Mais ça signifie qu'il faut tout de même rajouter un mot qui manque dans la liste en propriété de hiérarchie à savoir rang correspondant aux valeurs possibles.
Pour illustrer la suite, voici un schéma de ce qu'il va falloir faire à la suite de ce tri :
+---------------+ +-------------+
| interlocuteur | | hierarchie |
+---------------+ +-------------+
| nom | | rang |
| post_nom | +-------------+
| prenom |
+---------------+
Il va falloir faire ça pour vider la liste des mots. Ensuite, on va établir les relations existant entre ces différentes entités.
Attention, je n'ai indiqué là aucun identifiant, et à ce stade, ce n'est pas pertinent, on s'occupera de ça après.
Pour la relation, on sait qu'un interlocuteur a ou n'a pas un rang dans la hiérarchie, mais on sait dans le même temps qu'un rang correspond à zéro ou plusieurs interlocuteurs. On dit donc qu'un interlocuteur a 0 ou 1 rang dans la hiérarchie, et qu'un rang de la hiérarchie correspond à 0 à n interlocuteurs, et on va matérialiser ça sur le graphique comme ceci :
+---------------+ +-------------+
| interlocuteur | | hierarchie |
+---------------+ 0/1 0/n +-------------+
| nom |>----------| rang |
| post_nom | +-------------+
| prenom |
+---------------+
Ensuite, nous ajouterons des identifiants. Mais nous allons d'abord appliquer une convention de nommage. Ce n'est pas une obligation, mais je la recommande très vivement, ça simplifie énormément la lecture par la suite. Par convention, chaque entité aura un suffixe sous la forme d'un trigramme, trois lettres qui serviront par la suite de préfixe pour chaque propriété qui lui appartient. Ainsi, nous nommerons l'entité interlocuteur avec le suffixe int ce qui donnera interlocuteur_int, et hierarchie_hie. Si on l'applique ensuite aux propriétés, le schéma devient alors :
+-------------------+ +----------------+
| interlocuteur_int | | hierarchie_hie |
+-------------------+ 0/1 0/n +----------------+
| int_id |>----------| hie_rang |
| hie_id | +----------------+
| int_nom |
| int_post_nom |
| int_prenom |
+-------------------+
Et là, on commence à voir se dessiner notre modèle de données. Nos entités seront alors transformées en tables.
Est-ce que ça commence à vous parler ou bien je vous ai largué en cours de route ? Je suis parfaitement conscient que ce n'est pas du tout évident, et je me souviens encore fort bien des difficultés que j'ai pu rencontrer lorsque j'ai appris ces concepts, mais croyez-moi, c'est indispensable et si ça vous semble difficile aujourd'hui, dîtes-vous bien qu'avec la maitrise de cette méthode, ça va considérablement facilité les développements par la suite.
Bonjour Cyrano!
Jusque là, je vous suis très bien et comme je vous l'avez dit précédemment: j'essaye toujours de comprendre tout ce que vous m'apprenez. Donc, pour moi, vous êtes un véritable entraîneur, un entraîneur avec ses propres styles d'entraînement et pour devenir bon voire meilleur un jour, il faudra toujours me soumettre à vos manières d'analyser les choses.
Voici d'abord ce que j'ai retenu après avoir trié d'autres éléments de la liste que vous venez d'établir:
Exemple 1: je prend l'entité Témoin avec les propriétés nom, post nom et prénom.
je vais également utiliser une entité que j'appelle catégorie avec la propriété type
En respectant tous les principes que vous aviez donnés dans le précédent exemple, voici la relation que je trouve:
+---------------+ +----------------+
| Temoin_tem | | Categorie |
+---------------+ +----------------+
| tem_id | | cat_id |
| tem_nom | 1/1 1/1 | cat_type |
| tem_post_nom |>----------| |
| tem_prenom | +----------------+
| tem_DateNaiss |
| |
+---------------+
Un témoin peut être d’1 et 1 seul type dans la catégorie
Une catégorie est réservée à 1 et 1 seul témoin
Exemple 2: je prend l'entité Diocèse avec la propriété nom et l'entité paroisse avec les propiétés nom de la paroisse,date d’implantation
+---------------+ +----------------+
| Paroisse_par | | Diocese_dio |
+---------------+ +----------------+
| par_id | | dio_id |
| par_nom | 1/1 1/n | dio_nom |
| par_Date_Impl |>----------| |
| | +----------------+
+---------------+
Un diocèse comprend 1 ou n paroisses
1 ou n paroisses appartiennent à 1 et 1 seul diocèse
J'ai une préoccupation, pourquoi dans l'exemple que vous aviez donné, vous avez préféré utiliser seulement les trois propriétés (nom, post nom et prénom) et laisser la propriété date de naissance?
Bonjour Cyrano!
Jusque là, je vous suis très bien et comme je vous l'avez dit précédemment: j'essaye toujours de comprendre tout ce que vous m'apprenez. Donc, pour moi, vous êtes un véritable entraîneur, un entraîneur avec ses propres styles d'entraînement et pour devenir bon voire meilleur un jour, il faudra toujours me soumettre à vos manières d'analyser les choses.
Voici d'abord ce que j'ai retenu après avoir trié d'autres éléments de la liste que vous venez d'établir:
Exemple 1: je prend l'entité Témoin avec les propriétés nom, post nom et prénom.
je vais également utiliser une entité que j'appelle catégorie avec la propriété type
En respectant tous les principes que vous aviez donnés dans le précédent exemple, voici la relation que je trouve:
Temoin_tem (tem_id, tem_nom, tem_post_nom, tem_prenom, tem_DateNaiss)
Categorie ( cat_id, cat_type)
Un témoin peut être d’1 et 1 seul type dans la catégorie
Une catégorie est réservée à 1 et 1 seul témoin
Exemple 2: je prend l'entité Diocèse avec la propriété nom et l'entité paroisse avec les propiétés nom de la paroisse,date d’implantation
Diocese_dio ( dio_id, dio_nom)
Paroisse_par (par_id, par_nom, par_Date_Impl)
Un diocèse comprend 1 ou n paroisses
1 ou n paroisses appartiennent à 1 et 1 seul diocèse
J'ai une préoccupation, pourquoi dans l'exemple que vous aviez donné, vous avez préféré utiliser seulement les trois propriétés (nom, post nom et prénom) et laisser la propriété date de naissance?
Toutes mes excuses, je voulais également dessiner des tables à votre manière mais je n'y arrive pas.
Bonjour,
pas mal, j'ai trois éléments de réponses ;
- Sur la date de naissance, c'est un oubli de ma part.
- Sur les entité diocèse et paroisse, c'est correct.
- Sur les entités témoin et catégorie en revanche il y a erreur et voici les explications.
Le premier problème que ça pose, c'est que nous nous retrouvons avec des doublons sur les noms, prénoms et date de naissance qui sont déjà des propriétés de l'interlocuteur. Ensuite, est-ce qu'on peut considérer « témoin » comme une entité ? Et même question concernant « catégorie ». En outre, la relation entre témoin et catégorie telle que montrée ici indique qu'une catégorie appartient à un et un seul témoin, et qu'un témoins n'appartient qu'à une et une seule catégorie. Ça devrait alors nous amener à considérer la catégorie comme une propriété de témoin et non comme une entité a part entière. Mais il faut essayer de regarder ça plus globalement par rapport aux entités déjà définies.
Les nom, prénom et date de naissance étant déjà définis comme propriétés d'interlocuteur, il serait logique de relier témoin et interlocuteur. Mais la relation cette fois-ci sera 0/n-0/n. Si je reprends le schéma précédent et que j'y ajoute cette notion de témoin, ça donnerait ceci :
+-------------------+ +----------------+
| interlocuteur_int | | hierarchie_hie |
+-------------------+ 0/1 0/n +----------------+
| int_id |>----------| hie_id |
| hie_id | | hie_rang |
| int_nom |>-0/n +----------------+
| int_post_nom | | +---------------+
| int_prenom | | | Temoin_tem |
| int_datenaiss | | 0/n +---------------+
+-------------------+ |--------| tem_id |
| tem_type |
+---------------+
Quelques explications
Un interlocuteur pourrait être un paroissien ou bien pourrait être un ministre. Par ailleurs, il pourrait être le parrain (ou la marraine) lors d'un baptême, ou bien être le témoin d'un des mariés lors de noces, Voire même les deux successivement. Donc ici, la relation est qu'un interlocuteur peut être témoin (au sens large du terme) 0 à n fois.
L'entité témoin permet de définir sa catégorie : parrain, marraine, témoin d'un mariage, etc..) : donc nous pouvons faire sauter l'entité « catégorie » et ajouter à « témoin » la propriété « type ». Et comme il s'agit de définir un type de témoin, ça peut concerner 0 à n interlocuteurs.
La relation ici est particulière parce que lors de la création du « Modèle Physique de Données », nous allons voir apparaitre une table relationnelle intermédiaire entre interlocuteur et témoin. C'est pour cette raison que le schéma ci-dessus ne comporte pas de clé étrangère tem_id dans l'entité interlocuteur, pas plus que int_id dans l'entité témoin.
Ça ne va pas être nécessairement simple à saisir, mais là, ça implique que nous devons introduire une autre entité en relation avec ces deux là : c'est la cérémonie elle-même. Là où ça va se compliquer, c'est que nous allons avoir ce qu'on appelle une relation à trois pattes, ce qui en général fatigant à gérer si on s'y prend de travers.
L'important, c'est aussi d'essayer de ne pas se limiter à une partie du modèle : tous ces éléments sont liés d'une manière ou d'une autre, donc il faut garder une vue d'ensemble. Par exemple, un interlocuteur IX est un paroissien de l'église EX située dans le diocèse DX, il est parrain de IY lors d'une cérémonie de baptême dans la chapelle EY présidée par l'interlocuteur IZ qui est prêtre de cette chapelle. Le mois suivant, les interlocuteurs iV et iW se marient dans l'église EY et notre interlocuteur IX est témoin de IV... et ainsi de suite.
Commencez-vous à voir la complexité que ça peut prendre ? Il faut tâcher de simplifier en distinguant nos entités de façon à ne pas avoir de doublons tout en pouvant identifier l'ensemble des données pour une cérémonie donnée selon des critères spécifiques.
Pour résumer
Il faut essayer d'imaginer les différents Cas d'utilisation qu'on est susceptible de rencontrer de façon à identifier certains éléments qui seront importants : par exemple des dates sont souvent oubliées et ajoutées après coup mais de façon inappropriée, introduisant de ce fait des erreurs de conception.
Donc essayez de commencer par identifier toutes les entités, ajoutez leurs propriétés spécifiques et ensuite établissez les relations, mais sans précipitation sur cette dernière partie.
Bonjour Cyrano!
Voici d'autres raisonnements de ma part:
Interlocuteur_int(int_id, int_nom, int_postnom, int_prenom)
sera en relation avec
chapelle_cha(cha_id, cha_nom, cha_date_implantation)
Règle de Gestion: 1 ou n interlocuteurs fréquentent une seule chapelle.
Interlocuteur_int(int_id, int_nom, int_postnom, int_prenom)
sera en relation avec
sacrement_sac(sac_id, sac_libelle)
Règle de Gestion: 1 ou n sacrement sont reçus par 0,n interlocuteurs.
Remarque: 1. Etant donné que nous voulons à tout pris éviter la rédondance dans la base de données, je voulais écraser dans la liste l'entité candidat parce qu'elle reprend les mêmes propriétés de l'entité intelocuteur mais un problème se présente au niveau de la relation Interlocuteur_int et sacrement_sac, on ne saura pas le temoin de l'interlocuteur quand il va recevoir son sacrement.
- Avant que je continue, un autre problème se présente au niveau de la relation Interlocuteur_int et sacrement_sac, difficile d'avoir les informations sur le condjoint(e) quand il s'agit du sacrement de mariage, étant donné que le condjoint(e) peut être un des paroissiens ou pas.
Salut,
effectivement, et c'est ce que j'indiquais précédemment avec une relation n/n.
Ici, le lien entre interlocuteur et lieu de culte est sensiblement pareil. Ce ne sera pas « interlocuteur fréquente 1 et 1 seule chapelle » et « chapelle reçoit 1 à n interlocuteurs » : un interlocuteur pourra fréquenter une chapelle habituellement et occasionnellement se rendre dans une autre, voire même une chapelle d'un autre diocèse, et pour les cas qui nous intéressent, ça pourra arriver lorsque par exemple il sera témoin d'un mariage qui ne se déroule pas dans sa paroisse.
Mais ça ouvre là une question fonctionnelle : a-t-on réellement besoin de savoir à quelle paroisse appartient un interlocuteur ? Je suis tenté de répondre non à cette question dans la mesure où ce qu'on veut enregistrer, ce sont les informations relatifs à un sacrement. On aura donc en fin de comptes les sacrements qu'a reçu tel ou tel interlocuteur, et on pourra donc savoir dans quelle paroisse il a reçu tel ou tel sacrement. Mais savoir s'il fréquente habituellement telle ou telle paroisse ne présente ici aucun intérêt.
Essayons de résumer : quelles sont nos entités ?
- Diocèse
- Paroisse
- Sacrement
- Cérémonie
- Interlocuteur
- Ministre
- Témoins
- Groupe (?)
Je mets à dessein un point d'interrogation vis-à-vis du groupe : Est-il pertinent de gérer cet aspect d'une paroisse par rapport aux sacrements ? Si on reprend la définition initiale, la réponse est non et nous avons alors ce que j'appelais « de la pollution » dans notre dictionnaire de données. La pollution, ce sont des information qui certes existent dans l'environnement considéré mais n'ont en réalité aucun lien direct voire parfois même aucun lien indirect avec le sujet traité.
Donc à priori, je pars du principe qu'on oublie la notion de groupes. Qu'est-ce qui nous reste et comment est-ce qu'on relie tout ça ?
- Nous avons des diocèses;
- Nous avons les sacrements;
- Nous avons des paroisses : une paroisse appartient à un et un seul diocèse, et un diocèse comprend 1 à n paroisses;
- Nous avons les ministres du culte :
- un ministre est en charge de 1 à n paroisses;
- une paroisse est sous la garde d'un et un seul ministre.
- Pour les interlocuteurs, il y a plusieurs éléments, mais nous verrons ici le lien avec les ministres :
- Un ministre correspond à un et un seul interlocuteur;
- un Interlocuteur correspond à 0 ou 1 ministre;
- Il nous reste les cérémonies :
- une cérémonie est célébrée par 1 à n ministres (il peut y avoir concélébration, donc on ne peut pas dire 1 et 1 seul);
- Un ministre célèbrera 0 à n cérémonies;
- Une cérémonie célèbre la dispense d'un et un seul sacrement;
- Un sacrement sera donné lors de 0 à n cérémonies;
- ...
Pour l'instant, ça nous donne le schéma suivant :
+-----------------+ +---------------+ +----------+
| t_sacrement_sac | | t_diocese_dio | | paroisse |
+-----------------+ +---------------+ 1/n 1/1 +----------+
| sac_id | | dio_id |--------------<| par_id |
| sac_libelle | | dio_nom | | par_nom |
+-----------------+ +---------------+ +----------+
| 0/n V 1/1
| |
| |
| |
^ 1/1 | 1/n
+-----------------+ +----------------+
| t_ceremonie_cer | | t_ministre_min |
+-----------------+ 1/n 0/n +----------------+
| cer_id |>-------------------------------------------<| min_id |
| cer_date | | min_titre |
+-----------------+ +----------------+
V
| 0/n
|
|
|
+--------------+ +---------------------+ |
| t_temoin_tem | | t_interlocuteur_int | |
+--------------+ +---------------------+ 0/1 |
| tem_id | | int_id |-------------
| tem_type | | int_nom |
+--------------+ | int_prenom |
| int_datenaissance |
+---------------------+
On a presque terminé, je vais vous laisser établir les dernières relations pour voir si vous saisissez bien le concept général. Bien entendu, si dans les descriptions que j'ai faites des relations il y a des erreurs, il faudra les corriger en les motivant.
Bonjour Cyrano!
S'agissant du sacrement de mariage, vu que c'est un sacrement qui prend en compte les informations de deux personnes opposées (homme et femme), comment allons-nous le représenter? je pense que c'est la question qui m'embrouille encore.
Salut,
C'est moins compliqué que ça en a l,air. La difficulté réside sans doute dans le fait que tout ne sera pas géré par la base de données, une partie devra être mise en œuvre par programmation, donc dans la partie PHP.
Donc à ce stade, il convient de terminer ce schéma de relations. Pour éclairer un peu le chemin, voici quelques indications :
- On peut rajouter dans l'entité
t_interlocuteur_intla propriétéint_civilitequi permettra de distinguer un homme d'une femme; - La relation qui manque est triple : un interlocuteur participe à une cérémonie et a un rôle de témoin, encore qu'ici il pourrait y avoir une ambiguïté avec ce terme de « témoin ». Il faut donc convenir ici de ce qu'on entend exactement par « type de témoin ». Ça peut être un témoin de mariage, un parrain, une marraine ou même encore celui ou celle qui reçoit le sacrement. Dans le cas d'un mariage, on aura deux personnes dans ce cas et il conviendra de prévoir un contrôle qui vérifie que deux personnes qui seront les mariés ont une civilité différente.
Il y a un détail que je n'ai pas mentionné précédemment à propos de la convention utilisée pour nommer les entités : j'emploie un préfixe, ici on voit pour chacune un « t_ » et un suffixe composé de trois lettres.
Pour le préfixe, il faut comprendre « t » pour « table » tout court. Dans le modèle physique de données qui sera construit à partir de ce modèle conceptuel, nous allons voir apparaitre de nouvelles tables qu'on dit « relationnelles », et qu'on préfixera donc avec « r_ », et qui auront des clés primaires composites faites de deux clés étrangères. Mais on en reparlera le moment venu.
Même si vous n'êtes pas sûr, essayez et montrez-moi ce que vous pensez qu'il faille faire pour terminer ces relations dans le modèle conceptuel, on corrigera si nécessaire.
J'ajoute qu'il y a un détail que vous n'avez pas relevé qui pourrait nous causer des soucis ultérieurement, soucis concernant le lieu de la cérémonie. J'ai mis dans mon illustration un lien entre le ministre et sa paroisse, mais pas de lien entre la paroisse et la cérémonie. Or une cérémonie peut être dans une paroisse qui n'est pas celle du ministre, ou bien encore on peut avoir une cérémonie concélébrée par des ministres issus de paroisses différentes. Comment dès lors savoir où se passe la cérémonie.
La piste vers la solution : il y a une relation qui devient en réalité facultative et il faut en rajouter une qui manque encore sur le schéma.
Note : pour la mise en forme dans ce forum, il faut utiliser la syntaxe Markdown. Pour le schéma tel que je l'ai présenté plus haut, ou pour du code, il faut laisser une ligne vide, le schéma ou le code avec un décalage de 4 espaces vers la droite, et encore une ligne vide.
Salut!
Markdown me complique en tout cas mais je vais tout de même concevoir ce ces modèles. Merci beaucoup!
Salut,
pour la Markdown, c'est pas dramatique, au pire, j'éditerai le message pour le remettre en forme.
Bonjour Cyrano!
Après avoir revu le modèle que vous aviez proposé, j'ai eu quelques suggestions par rapport aux relations ci-après:
Les cardinalités (1/n pour paroisse et 1/1 pour ministre) qui interviennent dans la relation entre paroisse et ministre, devaientt changer en 1/1 pour la paroisse et 1/n pour le ministre parce que dans une paroisse, on peut avoir plusieurs ministres. Nous savons que, une paroisse est à la charge d'un curé et dans une paroisse, on retrouve également les abbés.
Pour la relation entre cérémonie et sacrement, je pensais tout de même que la cardinalité 0/n pour la cérémonie devait changer en 1/n parce que, on ne peut célébrer un sacrement dans une cérémonie. Tant qu'il y aura un sacrement à célébrer, il faudra qu'il existe au moins une ou plusieurs cérémonies dans lesquelles ledit sacrement sera célébré.
Il n'y a pas une relation entre la table cérémonie et interlocuteur?
Voici ce que j'ai pu faire, je m'estime pas avoir réalisé les plus importants mais je voulais quand même essayer ce que vous m'aviez déjà appris:
CREATE TABLE T_Interlocuteur_Int (
Int_id int(11) AUTO_INCREMENT NOT NULL,
Int_nom varchar(100) NOT NULL,
Int_Postnom varchar(100) NOT NULL,
Int_Prenom varchar(100) NOT NULL,
Int_DateNaiss date NOT NULL,
Int_LieuNaiss varchar(100) NOT NULL,
Int_NomPere varchar(200) NOT NULL,
Int_NomMere varchar(200) NOT NULL,
Int_Sexe varchar(100) NOT NULL,
PRIMARY KEY (Int_id)
);
CREATE TABLE T_ministre_Min (
Min_id int(11) AUTO_INCREMENT NOT NULL,
Min_Titre varchar(100) NOT NULL,
PRIMARY KEY (Min_id)
);
-- A ce stade, j'ai utilisé les cardinalités 0/n pour l'interlocuteur et
-- 0/1 pour le ministre avec l'association Occuper
CREATE TABLE Occuper (
Min_id int(11),
Int_id int(11)
);
ALTER TABLE Occuper ADD FOREIGN KEY (Min_id) REFERENCES T_ministre_Min (Min_id);
ALTER TABLE Occuper ADD FOREIGN KEY (Int_id) REFERENCES T_Interlocuteur_Int (Int_id);
CREATE TABLE T_Temoin_Tem (
Tem_id int(11) AUTO_INCREMENT NOT NULL,
Tem_Type varchar(100) NOT NULL,
PRIMARY KEY (Tem_id)
);
-- A ce stade, j'ai utilisé les cardinalités 0/n pour l'interlocuteur et
-- 0/n pour le temoin avec l'association devenir
CREATE TABLE Devenir (
Tem_id int(11),
Int_id int(11)
);
ALTER TABLE Devenir ADD FOREIGN KEY (Tem_id) REFERENCES T_Temoin_Tem (Tem_id);
ALTER TABLE Devenir ADD FOREIGN KEY (Int_id) REFERENCES T_Interlocuteur_Int (Int_id);
-- Entre la table cérémonie et la table paroisse, les cardinalités utilisées sont
-- de 1/n pour la cérémonie et 1/1 pour la paroisse avec l'association organiser.
-- Donc, dans une paroisse, une ou plusieurs cérémonies y sont organisées.
CREATE TABLE T_Ceremonie_Cer (
Cer_id int(11) AUTO_INCREMENT NOT NULL,
Cer_date date,
Cer_heure time,
Par_id int(11),
Sac_id int(11),
PRIMARY KEY (Cer_id)
);
ALTER TABLE T_Ceremonie_Cer ADD FOREIGN KEY (Par_id) REFERENCES T_Paroisse_Par (Par_id);
ALTER TABLE T_Ceremonie_Cer ADD FOREIGN KEY (Sac_id) REFERENCES T_Sacrement_Sac (Sac_id);
-- Entre la table cérémonie et la table sacrement, les cardinalités utilisées sont de 1/n
-- pour la cérémonie et 1/1 pour la sacrement avec l'association consacrer. Un et un seulement
-- sacrement peut être consacré dans une ou plusieurs cérémonies.
CREATE TABLE T_Paroisse_Par (
Par_id int(11) AUTO_INCREMENT NOT NULL,
Par_nom varchar(100) NOT NULL,
Par_DateImpl date NOT NULL,
Qua_id int(11) NOT NULL,
Dio_id int(11) NOT NULL,
PRIMARY KEY (Par_id)
);
CREATE TABLE T_Sacrement_Sac (
Sac_id int(11) AUTO_INCREMENT NOT NULL,
Sac_libelle varchar(100) NOT NULL,
PRIMARY KEY (Sac_id)
);
-- Entre la table cérémonie et la table ministre, les cardinalités utilisées sont de 1/n pour la
-- cérémonie et 1/n pour le ministre avec l'association Celebrer. Une cérémonie est célébrée.
CREATE TABLE Celebrer (
Min_id int(11) NOT NULL,
Cer_id int(11) NOT NULL
);
CREATE TABLE T_Ville_Vil (
Vil_id int(11) AUTO_INCREMENT NOT NULL,
Vil_nom varchar(100) NOT NULL,
PRIMARY KEY (Vil_id)
);
CREATE TABLE T_Commune_Com (
Com_id int(11) AUTO_INCREMENT NOT NULL,
Com_nom varchar(100) NOT NULL,
Vil_id int(11) NOT NULL,
PRIMARY KEY (Com_id)
);
CREATE TABLE T_Quartier_Qua (
Qua_id int(11) AUTO_INCREMENT NOT NULL,
Qua_nom varchar(100) NOT NULL,
Com_id int(11) NOT NULL,
PRIMARY KEY (Qua_id)
);
CREATE TABLE T_Diocese_Dio (
Dio_id int(11) AUTO_INCREMENT NOT NULL,
Dio_nom varchar(100) NOT NULL,
Vil_id int(11) NOT NULL,
PRIMARY KEY (Dio_id)
);
Je n'ai encore rien créé pour ce qui de la base des données, si j'ai opté à la méthode de code sql ce parce que j'ai remarqué qu'à travers cette méthode, certains éléments seront un peut clair vu que je n'ai pas encore maîtrisé le système Markdown.
Je ne sais pas mais il peut y avoir manqué quelques relations, je compte à vous!
Ok, j'ai remis en forme et au passage j,ai corrigé des erreurs dans certaines requêtes de création.
Mais ce n'est pas tout à fait ce que j'attendais : le schéma des relations n'est pas complet et c'est ça qu'il faut faire en premier lieu.
Pour les points 1 et 2, voici une réponse :
- D'abord, il faut bien comprendre que la cardinalité indique le nombre de relations possibles avec l'entité qui est reliée. Donc si dans la relation paroisse/ministre on a 1/n - 1/1, c'est normal : un ministre ne peut être ministre que d'une seule paroisse, quel que soit son rang dans la hiérarchie ecclésiastique, et une paroisse peut avoir 0 à n ministre : une petite chapelle de campagne pourrait en pas avoir de ministre du tout et c'est celui d'une paroisse voisine qui vient ponctuellement faire des célébrations.
- Pour des raisons similaires, la relation entre sacrement et cérémonie indique qu'un sacrement peut être célébré 0 à n fois, alors qu'une cérémonie dispense un et un seul sacrement à la fois. Il pourrait arriver occasionnellement qu'on assiste à plusieurs cérémonies en une seule, mais techniquement, ce seront autant de cérémonies distinctes auxquelles on reliera individuellement les liens qui la concerne exclusivement.
Allez, je vais donner un élément supplémentaire et compléter partiellement le schéma, mais il faudra le terminer :
+-----------------+ +----------------+ +---------------+
| t_sacrement_sac | | t_paroisse_par | | t_diocese_dio |
+-----------------+ +----------------+ 1/1 1/n +---------------+
| sac_id | | par_id |>--------------| dio_id |
| sac_libelle | | par_nom | | dio_nom |
+-----------------+ +----------------+ +---------------+
| 0/n V 1/1
| |________________________
| |
| |
^ 1/1 | 1/n
+-----------------+ +----------------+
| t_ceremonie_cer | | t_ministre_min |
+-----------------+ +----------------+
| cer_id | 1/n | min_id |
| cer_date |>------------------------------------------<| min_titre |
+-----------------+ 1/n +----------------+
V 1/n V
| | 0/n
|_______________________________ |
| | 1/1 |
| 1/1 ^ |
+--------------+ +---------------------+ |
| t_temoin_tem | | t_interlocuteur_int | |
+--------------+ +---------------------+ 0/1 |
| tem_id | | int_id |-------------
| tem_type | | int_civilite |
+--------------+ | int_nom |
| int_prenom |
| int_datenaissance |
+---------------------+
J'ai déplacé certaines entités pour pouvoir terminer de telle sorte que ça reste lisible. On passera au modèle physique ensuite.
Bonjour Cyrano!
Partant d'un détail que vous avez relevé ci-haut disant: "qu'il y avait un soucis ultérieurement, soucis concernant le lieu de la cérémonie. J'ai mis dans mon illustration un lien entre le ministre et sa paroisse, mais pas de lien entre la paroisse et la cérémonie. Or une cérémonie peut être dans une paroisse qui n'est pas celle du ministre, ou bien encore on peut avoir une cérémonie concélébrée par des ministres issus de paroisses différentes."
Pour ce cas, j'avais déjà représenté une relation suivante:
T_Ceremonie_Cer (1,1)-----------(1,n) T_Paroisse_Par.
Quand j'ai relu très bien le problème évoqué, j'ai très vite compris que cette relation ne proposait pas encore une bonne solution.
Cependant, j'ai pensé à une relation ternaire qui sera composée par l'entité paroisse, cérémonie et ministré
T_Ceremonie_Cer (1,n)-------(Concelebrer)---------(1,n) T_Paroisse_Par (1,n) T_Ministre_Min
Pour dire que, Dans une ou plusieurs paroisses, une ou plusieurs cérémonie sont concélébrés par un ou plusieurs ministres.
Que pensez-vous de cette dernière relation.
Bonjour Cyrano!
Partant d'un détail que vous avez relevé ci-haut disant: "qu'il y avait un soucis ultérieurement, soucis concernant le lieu de la cérémonie. J'ai mis dans mon illustration un lien entre le ministre et sa paroisse, mais pas de lien entre la paroisse et la cérémonie. Or une cérémonie peut être dans une paroisse qui n'est pas celle du ministre, ou bien encore on peut avoir une cérémonie concélébrée par des ministres issus de paroisses différentes."
Pour ce cas, j'avais déjà représenté une relation suivante:
T_Ceremonie_Cer (1,1)-----------(1,n) T_Paroisse_Par.
Quand j'ai relu très bien le problème évoqué, j'ai très vite compris que cette relation ne proposait pas encore une bonne solution.
Cependant, j'ai pensé à une relation ternaire qui sera composée par l'entité paroisse, cérémonie et ministré
T_Ceremonie_Cer (1,n)-------(Concelebrer)---------(1,n) T_Paroisse_Par (1,n) T_Ministre_Min
Pour dire que, Dans une ou plusieurs paroisses, une ou plusieurs cérémonie sont concélébrés par un ou plusieurs ministres.
Que pensez-vous de cette dernière relation?
C'est beaucoup trop compliqué pour rien.
Une cérémonie a lieu dans un endroit, et bien entendu un seul. Alors qu'elle peut être célébrée par un ou n ministre. Donc déjà, je ne peux pas créer une relation ternaire.
L'idée que vous indiquez au départ :
t_ceremonie_cer (1,1)-----------(1,n) t_paroisse_par
Est tout à fait valable, à un détail près : certaines paroisses peuvent (en théorie) ne jamais voir de cérémonie célébrant un sacrement, donc la modification que j'y apporterais serait :
t_ceremonie_cer (1,1)-----------(0,n) t_paroisse_par
Ce qui termine notre Modèle Conceptuel de Données (MCD) :
+-----------------+ +----------------+ +---------------+
| t_sacrement_sac | | t_paroisse_par | | t_diocese_dio |
+-----------------+ +----------------+ 1/1 1/n +---------------+
| sac_id | | par_id |>--------------| dio_id |
| sac_libelle | | par_nom | | dio_nom |
+-----------------+ +----------------+ +---------------+
| 0/n 0/n | V 0/1
| | |________________________
| | |
| | |
^ 1/1 | | 1/n
+-----------------+ | +----------------+
| t_ceremonie_cer | | | t_ministre_min |
+-----------------+ 1/1 | +----------------+
| cer_id |>---------------- 1/n | min_id |
| cer_date |>------------------------------------------<| min_titre |
+-----------------+ 1/n +----------------+
V 1/n V
| | 0/n
|_______________________________ |
| | 1/1 |
| 1/1 ^ |
+--------------+ +---------------------+ |
| t_temoin_tem | | t_interlocuteur_int | |
+--------------+ +---------------------+ 0/1 |
| tem_id | | int_id |-------------
| tem_type | | int_civilite |
+--------------+ | int_nom |
| int_prenom |
| int_datenaissance |
+---------------------+
Il pourrait persister un léger doute sur un point : la relation paroisse/ministre. Est-ce qu'une paroisse n'a jamais qu'un seul ministre en charge ou bien peut en avoir plus d'un ? La différence reste importante parce que ça va directement affecter la suite.
Il s'agit maintenant de le convertir en Modèle Physique de Données (MPD).
Pour aller à cette étape, il faut définir la réponse à la question qui traine ci-dessus.
Est-ce que jusque là, la logique de l'ensemble commence à vous apparaitre ?
Bonjour Cyrano!
je pense pour la relation paroisse/ministre, nous pourrons juste changer la cardinalité 0/1 de ministre pour 1/n étant donné que dans une paroisse, on peut avoir un ou plusieurs ministres.
Jusque là, la logique est très correcte, il n'y a pas à discuter, si vous voulez, je peux d'abord à partir de ce modèle, faire le modèle physique des données et afin vous allez me proposer la bonne solution.
Ok, encore que certaines paroisses peuvent ne pas avoir de ministre attitré, je pense en particulier à bon nombre de petites églises de campagne qui n'ont plus de curés depuis belle lurette, et qui sont donc desservies ponctuellement par le seul curé présent dans un des villages de la région. DOnc on peut partir sur une relation 0/n.
Le modèle physique
Alors maintenant, il faut construire le MPD à partir du MCD : est-ce que l'idée générale est claire ou bien est-ce qu'il faut quelques explications ? En quoi consiste cette opération en gros ?
Bonjour Cyrano!
j'aimerai bien avoir quelques explications, ça va permettre de m'améliorer d'avantage.
juste une preoccupation, la relation que vous avez mise entre la table témoin, la table cérémonie et la table interlocuteur est une relation ternaire ? ou c'est la table témoin qui est reliée à la table cérémonie avec les cardinalités 1/1 et 1/n, de même que la table interlocuteur reliée à la table cérémonie avec les cardinalités 1/1 et 1/n?
Salut,
c'est bien une relation ternaire, ce qu'on nomme une « trois pattes ».
Pour les explications : lorsqu'on passe du modèle conceptuel au modèle physique, les entités devient des tables, leurs propriétés en deviennent les colonnes. Et ensuite, on ajoute les clés étrangères selon les cardinalités entre les tables.
Relation simple
Exemple : la relation entre les entités diocèse et paroisse indique qu'une paroisse fait partie d'un et d'un seul diocèse, et qu'un diocèse comprend 1 à n paroisses. Donc la table paroisse va refléter cette relation en affichant une clé étrangère qui permettra d'identifier le diocèse auquel elle est rattachée. On aura donc des tables qui ressembleront à ceci :
+----------------+ +---------------+
| t_paroisse_par | | t_diocese_dio |
+----------------+ +---------------+
| par_id | PK |---------------| dio_id | PK |
| dio_id | FK | | dio_nom | |
| par_nom | | +---------------+
+----------------+
Ainsi, lorsqu'on voudra par exemple lister les paroisses d'un diocèse dont on connait l'identifiant, on pourra envoyer une requête de ce genre :
SELECT par_id, par_nom FROM t_paroisse_par WHERE dio_id = 1;
Si je voulais avoir aussi le nom du diocèse, il me faudrait faire une jointure, comme ceci :
SELECT
par.par_id,
par.par_nom,
dio.dio_nom
FROM t_paroisses_par par
INNER JOIN t_diocese_dio dio ON par.dio_id = dio.dio_id
WHERE dio.dio_id = 1;
Relation n/n
Prenons l'exemple de la relation cérémonie/ministre qui ressemble donc à ceci :
+-----------------+ +----------------+
| t_ceremonie_cer | | t_ministre_min |
+-----------------+ +----------------+
| cer_id | 1/n | min_id |
| cer_date |>---------<| min_titre |
+-----------------+ 1/n +----------------+
Là, nous ne pouvons pas mettre la clé primaire de l'une en clé étrangère dans l'autre, parce que ça bloquerait la relation à sens unique. Il faut donc créer une table relationnelle qui sera intercalée :
+-----------------+ +-----------------------+ +----------------+
| t_ceremonie_cer | | r_min_celebre_cer_mcc | | t_ministre_min |
+-----------------+ +-----------------------+ +----------------+
| cer_id | PK |---------| min_id | PK,FK |-----------| min_id | PK |
| cer_date | | | cer_id | PK,FK | | min_titre | |
+-----------------+ +-----------------------+ +----------------+
Voilà pour la base : je vous laisse construire le reste
Note : dans les tables, les mentions PK et FK signifient Primary Key (Clé primaire) et Foreign Key (Clé étrangère).
salut Cyrano!
je suis malade ce pourquoi il y a un retard de ma part. on m'a demandé de prendre un repos le temps que je me rétablisse
Pas de soucis, pour ce qui me concerne, ce n'est pas un soucis, j'ai largement de quoi m'occuper.
