Héritage

Bonjour à tous,

J'ai besoin d'un petit renseignement pour gérer l'héritage dans une bdd access.

J'ai vite fait un petit schéma,je crois que ce sera plus compréhensible.
La bdd estutilisée par une régie qui vend des espaces publicitaires.

Le commercial est un commercial de la régie,la régie n'est pas représentée dans les firmes.Un commercial ne peut être un employé d'une firme et vice-versa.
Un commercial se met en contact avec l'employé d'une firme pour lui vendre un espace pub.
Vu qu'Employe et Commercial ont des attributs communs,je me suis dit que ces deux derniers pourraient en hériter d'une table Personne qui est abstraite.
mais je ne vois pas quels attributs mettre dans Employé et Commercial...
Juste l'IDPersonne ou tous les attributs?


Merci encore
Pièce jointe 1333

Bonjour,

Je pense que si tu n'as pas d'attribut spécifique à mettre dans chacune des entité commercial et employé, la spécialisation de personne est du luxe. Un attribut supplémentaire pour typer ton entité est largement suffisant.
Sinon,
- soit tu n'implantes pas de table personne. Tu migres tous les attributs de personne et dans employé et dans commercial et tu complètes avec les attributs propres à chaque entité.
- soit tu assumes ta relation d'héritage jusqu'au bout, et tu crée 1 table personne avec les attributs communs, et 2 tables pour employe et commercial.

Les 2 sont envisageables avec leurs pros et cons propres.

Pour être un peu plus complet, je connais quatre façons d'implémenter l'héritage :

1. ne pas créer la table Personne, mais uniquement Commercial et Employé, avec chacune ses colonnes plus les colonnes correspondant aux attributs de Personne.
   Mon avis : ne permet pas de gérer les relations avec Personne (puisqu'elle n'existe pas)
2. créer une seule table avec l'ensemble des colonnes (Personne, Commercial, Employé), plus un Type (pratiquement obligatoire).
   Mon avis : permet de mélanger les torchons et les serviettes, ce qui peut se révéler dangereux
3. créer une Table Personne ne contenant que l'Identifiant et un Type (pas obligatoire), et des tables Employe et Commercial avec chacune ses colonnes.
   Mon avis : permet de gérer les relations avec Personne, tout en ayant des tables autonomes.
4. créer une table Personne avec toutes les colonnes communes et un Type (pas obligatoire) les tables Commercial et Employe ne contenant que les colonnes non communes.
   Mon avis : la plus propre d'un point de vue théorique et ma préférée. Il est possible de simuler la solution 1 et la solution 2 avec des vues. Les listes de Personnes sont particulièrement simples à obtenir.

Dans ton cas particulier, il ne semble pas y avoir de relation avec Personne, Employe n'a pas d'attributs propres, je suis donc, in fine, d'accord avec TheLeadingEdge :

Citation:

---

Envoyé par TheLeadingEdge

la spécialisation de personne est du luxe. Un attribut supplémentaire pour typer ton entité est largement suffisant.

---

Le seul "défaut" que je peux voir, c'est que tu ne pourras pas exprimer (par exemple) que Adresse est obligatoire (ou en tout cas autorisé) pour les commerciaux et interdit pour les employés, sauf à utiliser des TRIGGERS, alors que dans deux tables l'absence de colonnes interdit l'adresse pour les employés et si ces colonnes sont déclarées NOT NULL on peut les rendre obligatoires dans Commercial.

Bonjour,

Mediat,TheLead,je vais opter pour la solution des deux tables avec leurs propres attributs,je pense que ce sera beaucoup plus simple au niveau des requêtes et effectivement 'Personne' n'a aucune relation.
De plus mon promoteur m'a confirmé que même si j'ai utilisé uml pour la modélisation,vu que ma bdd est relationnelle,il n'y a aucune obligation d'y implémenter les notions d'héritage etc...chouette:P
Je me sens beaucoup mieux !

Merci à vous et à bientôt car j'aurai encore quelques au niveau de la sécurité.
Mais avant tout je vais aller potasser sur les différents tutoriels.

Heu....une petite quand même:
Quelle est la différence entre une transaction et un verrouillage?
Est-il nécessaire d' utiliser les deux?
Pour la présentation de mon tfe j'utilise MSDE et Access

Bonne journée ensoleillée

Re,

Verrouillage (''lock'') :
Tu poses 1 verrou sur des données pour interdire à d'autres appli. d'y accéder.
Par ex. tu veux empêcher la modification des données que tu viens de lire avant que tu n'aies fini de les traiter, ou tu veux empêcher la lecture de données que tu es en train de mettre à jour (voir ''dirty reads'', ''phantom read'' etc)
Transaction :
Utilisée pour protèger l'intégrité de données lors de modifications, ça n'a aucun intérêt pour des lectures.
Toutes les mises à jour (''insert'', ''update'', ''delete'') faites après le début d'une transaction doivent être validées (par 1 ''commit'') ou invalidées (explicitement par 1 ''rollback'' ou implicitement en cas de défaillance ds le sql ou de ton sgbd) avant la fin de la transaction. En cas de casse, on annule tt et ta base de données est aussi propre que s'il ne s'était rien passé.
Les niveaux d'isolation des données peuvent aller de tte la table à simplement 1 tuple, une page, etc, et empêcher les accès en lecture et écriture ou simplement en écriture, avec toutes les combinaisons possibles. De plus les SGBD ont selon les éditeurs des capacités différentes.

Attention : cela semble simple et efficace (et ça l'est) mais il vaut mieux en maitriser le concept et ses conséquences avant de l'utiliser. C'est à manier en ttes connaissance de cause, sous peine de gros soucis.

[edit] important : j'ai oublié de préciser que toutes les données utilisées entre ''begin trans'' et ''end trans'' sont verrouillées [/edit]

Histoire de completer avec un point de vue utilisation des architectures de la base :

Citation:

---

Envoyé par Médiat

Ne pas créer la table Personne, mais uniquement Commercial et Employé, avec chacune ses colonnes plus les colonnes correspondant aux attributs de Personne. Mon avis : ne permet pas de gérer les relations avec Personne (puisqu'elle n'existe pas)

---

Toute utilisation de l'objet Personne doit passer par une union de deux requetes (une par table fille), mais toutes mises à jour (insert, update & delete) sur un enregistrement se fera en une seule requete (ou deux pour les multi-enregistrements sur PERSONNE). Donc en effet, cette solution reste la plus efficace si PERSONNE ne sert pas ;)

Citation:

---

Envoyé par Médiat

créer une seule table avec l'ensemble des colonnes (Personne, Commercial, Employé), plus un Type (pratiquement obligatoire). Mon avis : permet de mélanger les torchons et les serviettes, ce qui peut se révéler dangereux

---

Precision : les champs spécifiques à un objet devient "nullable"... d'ou le danger car il faut pouvoir controlé qu'un objet de type X ne remplisse que ses champs. Cependant, le nombre de requetes est TOUJOURS limité à une seule, sans aucune jointure. Même si la solution reste dangereuse, elle en demeure la moins couteuse pour ce qui est des requetes SQL qui vont derriere. :mrgreen:

Citation:

---

Envoyé par Médiat

créer une Table Personne ne contenant que l'Identifiant et un Type (pas obligatoire), et des tables Employe et Commercial avec chacune ses colonnes. Mon avis : permet de gérer les relations avec Personne, tout en ayant des tables autonomes.

---

Je ne connaissais pas cette méthode. Je ne pense pas qu'elle apporte grand chose mis à part pour s'assurer de réduire le nombre de requetes lors des updates à 1 seule... toujours est il qu'il faudra un minimum de 2 requetes pour tout insert et delete. Par contre, en effet, aucune jointure ne sera faite pour récuperer un objet. ;)

Citation:

---

Envoyé par Médiat

créer une table Personne avec toutes les colonnes communes et un Type (pas obligatoire) les tables Commercial et Employe ne contenant que les colonnes non communes. Mon avis : la plus propre d'un point de vue théorique et ma préférée.

---

Bien que plus proche du concept objet, elle n'en demeure pas moins la plus couteuse, surtout si, par exemple, la classe mère est abstraite (comme ici pour Personne). Chaque SELECT sur la table nécessite une jointure. Quant aux insert/delete/update, il faudra en général faire autant de requetes que de hierarchie (ici 2, une pour Personne, l'autre pour Employé ou Commercial).:oops:

Voila, il faut donc étudier ton utilisation de la base avant de choisir la stratégie de modélisation la plus adequate ... si tu as de nombreux accès, il faut identifier si ce sont des ajouts, modifications ou bien de simple lectures, si tu n'a que peu d'accès, n'importe laquelle des opérations est utilisable puisque le cout de la requete restera négligeable pour ton appli ;)

Bonjour,

Merci TheLead pour les infos sur transaction et verrouillage.
J'aimerai juste avoir une petite précision,en utilisant la transaction,peut-on dès lors se passer du verrouillage?

Autre question :
Dans ma bdd j'ai une table Firme avec une association réflexive
Exemple:
j'ai dans mes firmes la société 'Gosselin'
Quand un commercial vend un espace publicitaire à cette firme,ce n'est pas elle qui signe le contrat,son budget publicitaire est géré par une agence de publicité qui est également encodé dans les firmes.
C'est donc l'agence qui est signataire et c'est à elle que la facture est envoyée.
Mais dans ma fiche je dois indiquer pour quelle firme l'espace a été réservé car l'agence'Du Bosch' peut être signataire pour plusieurs firmes.
D'après moi il aurait été logique d'avoir dans ma table firme une foreign key FirmeID associée à la clé primaire IDFirme.
Mais ça ne marche pas!
Existe-t-il une solution pour gérer ça?

Merci à vous tous

Citation:

---

Envoyé par keisha

Bonjour,

Merci TheLead pour les infos sur transaction et verrouillage.
J'aimerai juste avoir une petite précision,en utilisant la transaction,peut-on dès lors se passer du verrouillage?

---

Ma réponse sera OUI. Le verrouillage n'est que l'illustration d'une stratégie d'accès concurrentiel pessismiste (on se dit qu'il y a énormément de chance que quelqu'un touche à mon enregistrement pendant que je le modifie ou l'utilise). A l'opposé tu as l'accès concurrentiel optimiste justifié par la chance d'accès à la même donnée vraiment trop faible pour utiliser les verrous.

Il faut donc que, d'après l'utilisation de ta base, tu définisses si le besoin est la ou non... il faut aussi que tu regardes la longueur de tes transactions ... si elles restent plutot atomiques, le verrouillage n'est pas de rigueur, par contre, si ce sont des grosses opérations longues mais surtout critiques, le verrouillage est fortement préconisé ;)

Génial!Merci Bizur,j'ai bien compris ton explication et je peux dès lors confirmer que ma bdd je peux me passer des verrous.
Je t'explique en 2 mots:
Pour mon application j'ai 2 interfaces ,
Windows developpée sous delphi,pour l'administration,installée sur un seul poste.
Une interface web pour les commerciaux qui ne peuvent que consulter certaines données telles:
les firmes --> Ajout/modif
les suivis -->Ajout
les parutions -->Consultation
les réservations -->Ajout

Factures,paiements etc sont gérés par l'administrateur.

Je ne sais pas si tu as vu le fin de mon post,mais j'aimerai avoir une réponse concernant l'association réflexive,suis bloquée:cry:
Apparemment on ne sait pas la gérer sous accès,comment la contourner?


Mercii

hum a en lire ton probleme (et si je devais résumer)

Une firme peut avoir un signataire (intermédiaire) pour un contrat. Ce signataire fait partie de tes firmes, et tu as besoin de savoir, dans ton contrat, pour quelle firme le signataire a t il signé, c'est bien ca ?

Question : une firme peut etre signataire de plusieurs autres firmes ... mais est ce qu'une firme peut avoir plusieurs signataires ?!?
Si je comprend bien ton probleme avec la foreign key (et la contexte), tu n'arrive pas a determiner a partir de la firme signataire pour qui elle a signé (normal puisqu'elle apparaitra plusieurs fois en tant que clé étrangère.

Les solutions que je te propose sont les suivantes :
- Dans le contrat, tu ne met pas le signataire mais la firme concernée... et tu peux ainsi profiter de ta clé étrangère pour savoir qui a été le signataire... cependant, cela ne marche que si une firme n'a qu'un et qu'un seul signataire possible.
- Dans le contrat (la relation entre les trois), tu auras 2 champs pour firme ... l'une destinée au signataire, l'autre à la firme réellement concernée par le contrat (une asso ternaire en fait entre contrat et deux firmes).

Il existe bien évidemment d'autres solutions mais je pense que ces deux la essuie toutes les possibilités, reste à savoir exactement ce dont tu as besoin pour satisfaire tes règles de gestion du modèle. ;)

Re Bizur,
C'est exactement ça,
une firme (agence pub) peut etre le signataire pour plusieurs autres firmes
une firme n'a qu'un et un seul signataire

Le contrat tout comme la facture doivent être établis au nom de la firme signataire,

ça devrait me donner quelque chose de ce genre

Contrat N° 1
Date
Firme:agence xxx
son adresse tel fax N° tva
Signé pour firme:yyy


J'ai essayé de l'implémenter sous acces ça me donne ça,est-ce correct?

Pièce jointe 1466

Biz,

Bon je viens de me rendre compte que ça ne va pas,mon schéma dit le contraire de ce que veux!

Ca ressemble a ca oui, mais appelle ton champ FKFirme = Signataire pour que ca se lise mieux...

Sinon la modif a faire pour que cela passe, c'est de relier ton contrat a la firme finale (et non a la firme signataire)... tu pourra ainsi savoir pour qui s'adresse le contrat et qui l'a signé (en regardant l'enregistrement de la firme destinaire du contrat)

http://theleadingedge.developpez.com/images/keisha.jpg

J'arrive 1 peu à la bourre il me semble ;-)


Comme l'a dit Bizur tu peux aussi faire 1 ternaire entre commercial et firme. (1 patte pour la société cliente et 1 patte pour la société facturée.
Mais comme tu précises qu'1 firme ne peut avoir qu'un signataire, ne pas se priver si on peut éviter 1 association n-aire. C'est tjours mieux sans (avis perso). Ton association est donc entre commercial et firme qui commande.

Biz,TheLead,

axanti (ça veut dire merci dans ma langue :))
Ouf!Me sens mieux.

Je vous souhaite une bonne nuit et vous dis à bientôt !

Citation:

---

Envoyé par BizuR

Ca ressemble a ca oui, mais appelle ton champ FKFirme = Signataire pour que ca se lise mieux...

Sinon la modif a faire pour que cela passe, c'est de relier ton contrat a la firme finale (et non a la firme signataire)... tu pourra ainsi savoir pour qui s'adresse le contrat et qui l'a signé (en regardant l'enregistrement de la firme destinaire du contrat)

---

J'ai oublié de dire,moi non plus j'aime pas trop les ternaires,j'opte donc pour la solution ci-dessus.

Merci encore

Ce modèle présente cependant un défaut pour une entreprise je pense : l'historisation (oui, j'ai réfléchi dans on lit ^^). Ici, on saura au moment X quel signataire est employé par une firme, mais, si jamais la société change de signataire deux ans plus tard ... tu ne retrouveras plus ce signataire qui avait signé aujourd'hui ce contrat...

C'est donc à toi de voir si un tel paramètre est a prendre en compte ou non ;)

TheLeadingEdge >> Un peu en retard, certes, mais t'as quand même un schema bien plus parlant que des mots :roll:

Citation:

---

Envoyé par keisha

axanti (ça veut dire merci dans ma langue :))

---

Avec plaisir :)
Mais dis moi : c'est quelle langue ?
(sur ce coup là google est hors-jeu :mouarf: )

Hello TheLead ,
C'est du Swahili...Tu ne le parles pas???Pas possible !
C'est un peu l'anglais du continent africain,on le parle dans plusieurs pays avec quelques variantes(Kenya,rwanda,congo,somalie,comores,malawi etc)

Au fait,j'ai posté un nouveau message intitulé'Utilisation du TabControl avec DBGrid'
Pourrais-tu m'aider?

Axanti;)

Hello Bizur,

Je viens de lire ton message concernant la probabilité de changement de signataire.
Je ne pense pas qu'il soit nécessaire de le prendre en compte vu qu'en fin de compte le contrat appartient quand même à la firme(annonceur)
Le signataire ne fait que gérer et placer le budget publicitaire qui lui a été confié.
En espérant qu'aucun des membres du jury n'y pensera ;)

Merci à toi