Discussion :

[flatron]

Slt à tous !

Voila j'ai 3 tables :
la table Personne avce comme attribut Nom, Prenom,Naissance,Email,...
et 2 autres tables : Adherent avec comme attribut NumAdherent,Certif
et la table Intervenant avce comme attribut NumeroInterv,RaisonSocial,NumSiret

Alors ma question est de savoir comment réaliser un INSERT d'un adherent par ex ?
Faut-il faire 2 INSERT (1 ds la table Personne et un autre ds la Table Adherent?)

Sachant que la generation de ma BD, m'a inséré ds la table ADHERENT et PROF ,la clef primaire de la table Personne !

Merci d'avance !

[Magnus]

Si dans le schéma relationnel que vous avez généré, les tables ADHERENT et PROF possèdent une clé étrangère référençant la clé primaire de la table PERSONNE alors vous violerez les contraintes d'intégrité (qui doivent avoir été générées par la même occasion) si vous tentez d'insérer une ligne dans ADHERENT ou PROF dont la clé étrangère référence une clé primaire inexistante dans la table PERSONNE.

Concrètement : 1 insertion dans la table ADHERENT ou dans la table PROF implique :
- 0 insertion dans la table PERSONNE si la clé étrangère référence une clé primaire existante
- 1 insertion dans la table PERSONNE dans l'autres cas et surtout avant d'effectuer l'insertion dans la table ADHERENT ou dans la table PROF

[flatron]

Merci pour ta réponse

Dans les tables ADHERENT et PROF une clé primaire est générée, par heritage :

PERSONNE (pers_id,nom,prenom,tel....)
ADHERENT(pers_id,....)
PROF(pers_id,...)

Donc si je veux rajouter un adherent :
- il faut que je fasse in INSERT ds PERSONNE
- que je recupere son pers_id
- que je refasse un INSERT ds ADHERENT pour completer.

C'est bien ca ??

Y a vraiment pas d'interet de faire de l'heritage !
Je fais faire 3 requettes alors qu'une suffirait ! (ok il ya aurai de la redondance de donnée mais bon !)

Merci

[Magnus]

Y a vraiment pas d'interet de faire de l'heritage !
Je fais faire 3 requettes alors qu'une suffirait ! (ok il ya aurai de la redondance de donnée mais bon !)

Je ne suis pas spécialiste en conception de bases de données mais l'intérêt de l'héritage est justement d'avoir des infos différentes dans les tables mères / filles.
Ceci dit, avec des triggers et des contraintes d'intégrité, pour n'avez pas besoin de faire 3 requêtes mais 2 (ie celle de récupération de l'identifiant inséré).
Enfin, si votre conception est "correcte" alors vous ne devriez pas insérer d'enregistrement dans une table fille référençant une ligne de la table mère n'existant pas.

[fsmrel]

Bonsoir Flatron,


Il faut bien séparer les niveaux...

Au niveau conceptuel (Entité/relation, Merise), l’héritage est formellement connu des AGL tels que Win’Design ou PowerAMC.

Au niveau du Modèle Relationnel de Données, l’héritage de type (Type inheritance) est décrit très minutieusement dans les chapitres 11 à 16 (pages 241 à 357) de l’ouvrage de Date & Darwen "Databases, Types, and the Relational Model The Third Manifesto, Third Edition".

http://www.amazon.com/Databases-Type.../dp/0321399420

Au niveau du standard SQL (norme SQL pour faire plaisir à SQLpro), l’héritage de type est décrit avec les UDT (User defined-types), en même temps que l’instruction Create Type qui sert à les définir (Attention, l’héritage selon Date et selon le standard ne sont pas la même chose...)

Le standard SQL vous permet de définir un type Personne, des sous-types Adhérent et Intervenant, puis des tables correspondant à ces types. Le DDL pourrait ressembler plus ou moins à ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Create Type Personne_Type
    As (PersonneId ..., Nom ..., Prénom ...) ...
       Ref Is System Generated ;
 
Create Type Adhérent_Type Under Personne_Type
    As (NumAdhérent ..., Certif ...) ... ;
...
Create Table Personne Of Personne_Type
   (Ref Is PsnId System Generated,
    Primary Key (PersonneId)) ; 
 
Create Table Adhérent Of Adhérent_Type Under Personne ;
...

Maintenant, il s’agit de savoir si votre SGBD vous permet d’utiliser ces instructions, selon ce style.

Côté opérations :

Un INSERT d’un adhérent dans la table Personne se comporte comme d’habitude. Un INSERT dans la table Adhérent provoque l’ajout simultané d’une ligne dans Personne et d’une autre dans Adhérent.

Un DELETE d’un adhérent dans la table Personne se propage dans la table Adhérent. Un DELETE dans la table Adhérent se propage dans la table Personne.

Un UPDATE d’une colonne de la table Adhérent (obligatoirement via cette table) ne met à jour que cette dernière. Un UPDATE des autres colonnes (via Personne ou Adhérent) met à jour les deux tables (disons conceptuellement).

Maintenant, il y a le côté agaçant des choses :

Si l’on a créé la Personne Flatron, sans rien préciser pour la table Adhérent (ni pour la table Intervenant), le jour où Flatron devient adhérent, si l’on tente un INSERT dans la table Adhérent, le système rouspétera car il tentera aussi un INSERT dans la table Personne : il faudra donc commencer par supprimer Flatron dans la table Personne.

Inversement, si Flatron cesse d’être adhérent, il faut d’abord le supprimer avant de recréer une ligne dans la table Personne.

[flatron]

Déja merci pour vos réponses !

J'utilise SQL server Express ! Mais apres quelques recherche je suis tombé sur : Pas d'héritage de table

C'est dingue de ne pas implementer l'heritage !

Donc meme avec des triggers ou des Create type c'est foutu pour moi ?

Et quelles seraient les differences entre les CREATE Type et des TRIGGER
src : http://sql.developpez.com/modelisation/heritage/

Merci

[SQLpro]

Le plus si;ple est d'utiliser des procs stock pour si;plifier toutes les mises a jour (une ps pour insert/update, une ps pour le delete) et d'utiliser une vue pour pour les differentes personnes.

Exemple :
CREATE PROC P_IU_ADHERENT @...
AS


Des lors cote client vous n'aurez jamais qu'une seule operation a faire pour les maj et une seule "table" a interroger
A +

[fsmrel]

Bonsoir Flatron,

C'est dingue de ne pas implementer l'heritage !

C'est comme vous dites... Vous pouvez aussi préférer un autre SGBD (DB2, PostgreSQL, ...)

Attention : on lit par exemple dans la littérature PostgreSQL :

"A serious limitation of the inheritance feature is that indexes (including unique constraints) and foreign key constraints only apply to single tables, not to their inheritance children. This is true on both the referencing and referenced sides of a foreign key constraint...
These deficiencies will probably be fixed in some future release, but in the meantime considerable care is needed in deciding whether inheritance is useful for your problem."

On ne le lui fait pas dire... Et comme dit Laspalès à Chevallier : "C’est vous qui voyez !"

[flatron]

Slt et merci pour vos réponses !

Mais j'ai vu que je pouvez faire pratiquement la meme chose que SQL Pro qu'avec les triggers (src: http://sql.developpez.com/modelisation/heritage/)
en utilisant les assertions !

Y a t-il une difference ?

Merci

[fsmrel]

Bonsoir Flatron,

j'ai vu que je pouvez faire pratiquement la meme chose que SQL Pro qu'avec les triggers (src: http://sql.developpez.com/modelisation/heritage/) en utilisant les assertions !

Attention, une assertion et un trigger ne sont pas la même chose.

Selon le standard SQL, une assertion est l’expression d’une règle de gestion de données, d’une contrainte que l’on définit à l’aide de l’instruction CREATE ASSERTION (et donc directement comprise par le SGBDR), par opposition à ce que l’on programme dans du code qui échappe au contrôle du SGBDR (curieusement, les principaux éditeurs de SGBDR ne fournissent pas cette instruction, alors qu’au milieu des années soixante-dix, elle existait dans le prototype SYSTEM R d’IBM, ancêtre de tous les SGBDR). Par nature une assertion est statique.

Par exemple, considérons la table des salariés :

____Salarié (SalarieId, Salaire, Fonction, ...)

Pour signifier la règle,

« Les salariés ne peuvent avoir un salaire supérieur à celui du PDG »

on peut définir une assertion du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Create Assertion Regle_314
 Check (  
  Not Exists (
      Select SalarieId
      From   Salarié a 
      Where  Exists 
        (
         Select * 
         From   Salarié b 
         Where  a.Salaire > b.Salaire 
           And  b.Fonction = 'PDG'
      ))) ;

Un trigger permet d’héberger une requête équivalente, mais par détournement de ce pourquoi il est fait. En effet, "to trigger" se traduit par "déclencher" d’où une connotation plus dynamique que statique : "En cas d’Insert dans telle table, Update (de telle colonne de la table), Delete : déclencher telle(s) instruction(s) éventuellement en cascade". En outre, le développeur doit préciser à quel moment le trigger agit (Before, After). Programmer un trigger n’est pas trivial.

Tous les grands SGBDR proposent l’instruction CREATE TRIGGER qui permet donc de pallier plus ou moins facilement l’absence de l’instruction CREATE ASSERTION. Faute de grives...

[flatron]

Tjrs aussi performant ! Merci pour vos réponses !