Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Windows Windows Serveur SQL Serveur Pb Intégrité Référentielle : valeur nulle sur clef externe ?

Pb Intégrité Référentielle : valeur nulle sur clef externe ?

6 réponses
Avatar
News Groups
Bonjour,

Je constate que SQL Server permet comme Access de créer des clefs externes
composées d'un (ou
plusieurs) champ(s) sans que celui-ci (ou ceux-ci) ne soi(en)t affecté(s)
obligatoirement d'une contrainte de null interdit (propriété "Null Interdit"
du champ positionnée à "Non"). Ce qui à pour conséquence d'avoir dans la
table des valeurs nulles au niveau du champ composant la clef externe (la
clef primaire correspondante n'ayant aucune valeur nulle bien entendu!) .
Ceci étant possible par le choix des options de mise à jour en cascade et à
l'aide de déclencheurs ou procédures stockées.

exemple de jeu d'enregistrements :
- Table [VILLE] comportant la clef primaire NomDeVille dont les valeurs sont
:
NomDeVille
-------------
Paris
Lyon
Toulouse

-Table [ADRESSE] comportant la clef externe Ville correspondant à la clef
primaire Nom DeVille de la
table [VILLE] (relation 1 à plusieurs entre [VILLE] et [ADRESSE]) :
Nom Ville
------ ------
Durand Paris
Dupont Lyon
John
Smith Paris

- L'enregistrement n°3 a une valeur nulle pour le champ Ville !

Ma question est donc : comment cela est il possible si ce n'est que SQL
Server ne
respecte pas totalement le concept d'intégrité référentielle, de clef
primaire et externe ??...

Est ce le cas d'autre SGBDR : je sais que MySQL ne l'autorise pas, Access
oui !, qu'en est -il pour Oracle ou autre SGBDR. ?!

Si quelqu'un a les réponses, je serais curieux de savoir,
Merci à tous.
Signaler un problème avec ce contenu

6 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Patrice Scribe
Il me parait habituel et normal de pouvoir jouer indépendamment sur la
clause "NOT NULL" pour imposer ou non la relation.

La contrainte FK ne fait qu'indiquer ce que la relation doit respecter *si*
elle existe.
La clause NOT NULL sur le champ FK permet d'indiquer si cette relation est
obligatoire ou non.

Une personne habite obligatoirement dans une ville ou
Un personne habite dans 0 (si la ville où il habite ne m'est pas connue) ou
1 ville.

Dans les deux cas, l'intégrité référentielle est respectée car il n'est pas
possible d'indiquer une ville qui ne serait pas dans la liste des villes
(NULL n'étant pas une ville mais indiquant que la ville n'est pas connue).

Dans ton cas, il faut ajouter une contrainte NOT NULL sur la ville...

Patrice

--

"News Groups" a écrit dans le message de
news:3f672a86$0$2791$
Bonjour,

Je constate que SQL Server permet comme Access de créer des clefs externes
composées d'un (ou
plusieurs) champ(s) sans que celui-ci (ou ceux-ci) ne soi(en)t affecté(s)
obligatoirement d'une contrainte de null interdit (propriété "Null


Interdit"
du champ positionnée à "Non"). Ce qui à pour conséquence d'avoir dans la
table des valeurs nulles au niveau du champ composant la clef externe (la
clef primaire correspondante n'ayant aucune valeur nulle bien entendu!) .
Ceci étant possible par le choix des options de mise à jour en cascade et


à
l'aide de déclencheurs ou procédures stockées.

exemple de jeu d'enregistrements :
- Table [VILLE] comportant la clef primaire NomDeVille dont les valeurs


sont
:
NomDeVille
-------------
Paris
Lyon
Toulouse

-Table [ADRESSE] comportant la clef externe Ville correspondant à la clef
primaire Nom DeVille de la
table [VILLE] (relation 1 à plusieurs entre [VILLE] et [ADRESSE]) :
Nom Ville
------ ------
Durand Paris
Dupont Lyon
John
Smith Paris

- L'enregistrement n°3 a une valeur nulle pour le champ Ville !

Ma question est donc : comment cela est il possible si ce n'est que SQL
Server ne
respecte pas totalement le concept d'intégrité référentielle, de clef
primaire et externe ??...

Est ce le cas d'autre SGBDR : je sais que MySQL ne l'autorise pas, Access
oui !, qu'en est -il pour Oracle ou autre SGBDR. ?!

Si quelqu'un a les réponses, je serais curieux de savoir,
Merci à tous.










Avatar
Fred BROUARD
Visiblement tu ne maitrise pas les problèmes de modélisation...

Contrairement à ce que tu affirme ce comportement est parfaitement
normal. Il dépend du modèle abstrait que tu as donné.
Si relation 0..n alors possibilité de NULL dans la clef étrangère.
Si rlation 1..n alors imposssibilité de NULL dans la clef étrangères,
c'est à dire que chaque colonne comoposant la clef doit être créée avec
la contrainte NOT NULL.

Tes affirmations sur le concept des intégrités référentielles sont des
inepties lamentables.

Sache que SQL (la Norme, pas SQL Server en particulier) va bien au dela
de ce que tu pense.

A lire pour ta culture :
http://sqlpro.developpez.com/SQL_AZ_7b.html#SCHEMA73

Commencent par apprendre ce qu'est un modèle conceptuel de données
(MERISE ou UML) avant de commencer a affirmer que l'implémentation SQL
qui est en faite viole des règles de conception !!!

A +

News Groups a écrit:
Bonjour,

Je constate que SQL Server permet comme Access de créer des clefs externes
composées d'un (ou
plusieurs) champ(s) sans que celui-ci (ou ceux-ci) ne soi(en)t affecté(s)
obligatoirement d'une contrainte de null interdit (propriété "Null Interdit"
du champ positionnée à "Non"). Ce qui à pour conséquence d'avoir dans la
table des valeurs nulles au niveau du champ composant la clef externe (la
clef primaire correspondante n'ayant aucune valeur nulle bien entendu!) .
Ceci étant possible par le choix des options de mise à jour en cascade et à
l'aide de déclencheurs ou procédures stockées.

exemple de jeu d'enregistrements :
- Table [VILLE] comportant la clef primaire NomDeVille dont les valeurs sont
:
NomDeVille
-------------
Paris
Lyon
Toulouse

-Table [ADRESSE] comportant la clef externe Ville correspondant à la clef
primaire Nom DeVille de la
table [VILLE] (relation 1 à plusieurs entre [VILLE] et [ADRESSE]) :
Nom Ville
------ ------
Durand Paris
Dupont Lyon
John
Smith Paris

- L'enregistrement n°3 a une valeur nulle pour le champ Ville !

Ma question est donc : comment cela est il possible si ce n'est que SQL
Server ne
respecte pas totalement le concept d'intégrité référentielle, de clef
primaire et externe ??...

Est ce le cas d'autre SGBDR : je sais que MySQL ne l'autorise pas, Access
oui !, qu'en est -il pour Oracle ou autre SGBDR. ?!

Si quelqu'un a les réponses, je serais curieux de savoir,
Merci à tous.











--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************
Avatar
News Groups
Merci de ta réaction, un peut d'humilité de temps en temps ne fait pas de
mal!..



Sans vouloir me défendre, je dirais que mon message permettait de prêcher le
faux pour connaître le vrai : ta réponse à permis de mettre d'accord
l'ensemble des personnes qui ont pris part à la discussion sur le sujet et
qui ne concevais pas la relation 0 à n !! (une copie des pages Web mis en
référence dans ton mail leur à été distribuées...).

Une nota plus générale tout de même sur le sens de la valeur nulle : elle
peut signifier qu'une valeur est à associer mais inconnu à l'instant t ou
bien qu'il n'y a aucune valeur à indiquer, ex : une table composée de
Nom/Prenom/Second_Prenom, le champ Second_Prenom peut être null parce qu'il
n'est pas connu ou bien parce qu'il n'y en a pas. Comment traite tu cette
distinction de sens ?



Merci pour tes réponses (un peu directes tout de même !...mais après tout
cela pousse à acheter ton livre.)



"Fred BROUARD" a écrit dans le message de news:

Visiblement tu ne maitrise pas les problèmes de modélisation...

Contrairement à ce que tu affirme ce comportement est parfaitement
normal. Il dépend du modèle abstrait que tu as donné.
Si relation 0..n alors possibilité de NULL dans la clef étrangère.
Si rlation 1..n alors imposssibilité de NULL dans la clef étrangères,
c'est à dire que chaque colonne comoposant la clef doit être créée avec
la contrainte NOT NULL.

Tes affirmations sur le concept des intégrités référentielles sont des
inepties lamentables.

Sache que SQL (la Norme, pas SQL Server en particulier) va bien au dela
de ce que tu pense.

A lire pour ta culture :
http://sqlpro.developpez.com/SQL_AZ_7b.html#SCHEMA73

Commencent par apprendre ce qu'est un modèle conceptuel de données
(MERISE ou UML) avant de commencer a affirmer que l'implémentation SQL
qui est en faite viole des règles de conception !!!

A +

News Groups a écrit:
> Bonjour,
>
> Je constate que SQL Server permet comme Access de créer des clefs


externes
> composées d'un (ou
> plusieurs) champ(s) sans que celui-ci (ou ceux-ci) ne soi(en)t


affecté(s)
> obligatoirement d'une contrainte de null interdit (propriété "Null


Interdit"
> du champ positionnée à "Non"). Ce qui à pour conséquence d'avoir dans la
> table des valeurs nulles au niveau du champ composant la clef externe


(la
> clef primaire correspondante n'ayant aucune valeur nulle bien entendu!)


.
> Ceci étant possible par le choix des options de mise à jour en cascade


et à
> l'aide de déclencheurs ou procédures stockées.
>
> exemple de jeu d'enregistrements :
> - Table [VILLE] comportant la clef primaire NomDeVille dont les valeurs


sont
> :
> NomDeVille
> -------------
> Paris
> Lyon
> Toulouse
>
> -Table [ADRESSE] comportant la clef externe Ville correspondant à la


clef
> primaire Nom DeVille de la
> table [VILLE] (relation 1 à plusieurs entre [VILLE] et [ADRESSE]) :
> Nom Ville
> ------ ------
> Durand Paris
> Dupont Lyon
> John
> Smith Paris
>
> - L'enregistrement n°3 a une valeur nulle pour le champ Ville !
>
> Ma question est donc : comment cela est il possible si ce n'est que SQL
> Server ne
> respecte pas totalement le concept d'intégrité référentielle, de clef
> primaire et externe ??...
>
> Est ce le cas d'autre SGBDR : je sais que MySQL ne l'autorise pas,


Access
> oui !, qu'en est -il pour Oracle ou autre SGBDR. ?!
>
> Si quelqu'un a les réponses, je serais curieux de savoir,
> Merci à tous.
>
>
>
>
>
>
>
>

--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************



Avatar
Patrice Scribe
Pour moi, si il est NULL c'est que sa valeur est inconnue. Si c'est une
chaine vide, c'est qu'il n'a pas de second prénom.

NULL=valeur inconnue


Après un peu de mesure tout de même, il y a pas mal de cas dont sans doute
celui ci où il serait possible de faire l'impasse sur la valeur inconnue en
interdisant NULL et en mettant une chaine vide par défaut pour le second
prénom (on suppose que si le second prénom n'est pas indiqué c'st qu'il n'en
a pas)...

Patrice

--

"News Groups" a écrit dans le message de
news:3f681b54$0$20184$
Merci de ta réaction, un peut d'humilité de temps en temps ne fait pas de
mal!..



Sans vouloir me défendre, je dirais que mon message permettait de prêcher


le
faux pour connaître le vrai : ta réponse à permis de mettre d'accord
l'ensemble des personnes qui ont pris part à la discussion sur le sujet et
qui ne concevais pas la relation 0 à n !! (une copie des pages Web mis en
référence dans ton mail leur à été distribuées...).

Une nota plus générale tout de même sur le sens de la valeur nulle : elle
peut signifier qu'une valeur est à associer mais inconnu à l'instant t ou
bien qu'il n'y a aucune valeur à indiquer, ex : une table composée de
Nom/Prenom/Second_Prenom, le champ Second_Prenom peut être null parce


qu'il
n'est pas connu ou bien parce qu'il n'y en a pas. Comment traite tu cette
distinction de sens ?



Merci pour tes réponses (un peu directes tout de même !...mais après tout
cela pousse à acheter ton livre.)



"Fred BROUARD" a écrit dans le message de


news:

> Visiblement tu ne maitrise pas les problèmes de modélisation...
>
> Contrairement à ce que tu affirme ce comportement est parfaitement
> normal. Il dépend du modèle abstrait que tu as donné.
> Si relation 0..n alors possibilité de NULL dans la clef étrangère.
> Si rlation 1..n alors imposssibilité de NULL dans la clef étrangères,
> c'est à dire que chaque colonne comoposant la clef doit être créée avec
> la contrainte NOT NULL.
>
> Tes affirmations sur le concept des intégrités référentielles sont des
> inepties lamentables.
>
> Sache que SQL (la Norme, pas SQL Server en particulier) va bien au dela
> de ce que tu pense.
>
> A lire pour ta culture :
> http://sqlpro.developpez.com/SQL_AZ_7b.html#SCHEMA73
>
> Commencent par apprendre ce qu'est un modèle conceptuel de données
> (MERISE ou UML) avant de commencer a affirmer que l'implémentation SQL
> qui est en faite viole des règles de conception !!!
>
> A +
>
> News Groups a écrit:
> > Bonjour,
> >
> > Je constate que SQL Server permet comme Access de créer des clefs
externes
> > composées d'un (ou
> > plusieurs) champ(s) sans que celui-ci (ou ceux-ci) ne soi(en)t
affecté(s)
> > obligatoirement d'une contrainte de null interdit (propriété "Null
Interdit"
> > du champ positionnée à "Non"). Ce qui à pour conséquence d'avoir dans


la
> > table des valeurs nulles au niveau du champ composant la clef externe
(la
> > clef primaire correspondante n'ayant aucune valeur nulle bien


entendu!)
.
> > Ceci étant possible par le choix des options de mise à jour en cascade
et à
> > l'aide de déclencheurs ou procédures stockées.
> >
> > exemple de jeu d'enregistrements :
> > - Table [VILLE] comportant la clef primaire NomDeVille dont les


valeurs
sont
> > :
> > NomDeVille
> > -------------
> > Paris
> > Lyon
> > Toulouse
> >
> > -Table [ADRESSE] comportant la clef externe Ville correspondant à la
clef
> > primaire Nom DeVille de la
> > table [VILLE] (relation 1 à plusieurs entre [VILLE] et [ADRESSE]) :
> > Nom Ville
> > ------ ------
> > Durand Paris
> > Dupont Lyon
> > John
> > Smith Paris
> >
> > - L'enregistrement n°3 a une valeur nulle pour le champ Ville !
> >
> > Ma question est donc : comment cela est il possible si ce n'est que


SQL
> > Server ne
> > respecte pas totalement le concept d'intégrité référentielle, de clef
> > primaire et externe ??...
> >
> > Est ce le cas d'autre SGBDR : je sais que MySQL ne l'autorise pas,
Access
> > oui !, qu'en est -il pour Oracle ou autre SGBDR. ?!
> >
> > Si quelqu'un a les réponses, je serais curieux de savoir,
> > Merci à tous.
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
> Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
> Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
> ****************** mailto: ******************
>




Avatar
News Groups
Merci pour ces remarques,

La méthode me convient, même si j'avoue avoir toujours quelques résistance
quant à l'utilisation des chaînes vides.

Merci.



"Patrice Scribe" a écrit dans le message de news:

Pour moi, si il est NULL c'est que sa valeur est inconnue. Si c'est une
chaine vide, c'est qu'il n'a pas de second prénom.

NULL=valeur inconnue


Après un peu de mesure tout de même, il y a pas mal de cas dont sans doute
celui ci où il serait possible de faire l'impasse sur la valeur inconnue


en
interdisant NULL et en mettant une chaine vide par défaut pour le second
prénom (on suppose que si le second prénom n'est pas indiqué c'st qu'il


n'en
a pas)...

Patrice

--

"News Groups" a écrit dans le message de
news:3f681b54$0$20184$
> Merci de ta réaction, un peut d'humilité de temps en temps ne fait pas


de
> mal!..
>
>
>
> Sans vouloir me défendre, je dirais que mon message permettait de


prêcher
le
> faux pour connaître le vrai : ta réponse à permis de mettre d'accord
> l'ensemble des personnes qui ont pris part à la discussion sur le sujet


et
> qui ne concevais pas la relation 0 à n !! (une copie des pages Web mis


en
> référence dans ton mail leur à été distribuées...).
>
> Une nota plus générale tout de même sur le sens de la valeur nulle :


elle
> peut signifier qu'une valeur est à associer mais inconnu à l'instant t


ou
> bien qu'il n'y a aucune valeur à indiquer, ex : une table composée de
> Nom/Prenom/Second_Prenom, le champ Second_Prenom peut être null parce
qu'il
> n'est pas connu ou bien parce qu'il n'y en a pas. Comment traite tu


cette
> distinction de sens ?
>
>
>
> Merci pour tes réponses (un peu directes tout de même !...mais après


tout
> cela pousse à acheter ton livre.)
>
>
>
> "Fred BROUARD" a écrit dans le message de
news:
>
> > Visiblement tu ne maitrise pas les problèmes de modélisation...
> >
> > Contrairement à ce que tu affirme ce comportement est parfaitement
> > normal. Il dépend du modèle abstrait que tu as donné.
> > Si relation 0..n alors possibilité de NULL dans la clef étrangère.
> > Si rlation 1..n alors imposssibilité de NULL dans la clef étrangères,
> > c'est à dire que chaque colonne comoposant la clef doit être créée


avec
> > la contrainte NOT NULL.
> >
> > Tes affirmations sur le concept des intégrités référentielles sont des
> > inepties lamentables.
> >
> > Sache que SQL (la Norme, pas SQL Server en particulier) va bien au


dela
> > de ce que tu pense.
> >
> > A lire pour ta culture :
> > http://sqlpro.developpez.com/SQL_AZ_7b.html#SCHEMA73
> >
> > Commencent par apprendre ce qu'est un modèle conceptuel de données
> > (MERISE ou UML) avant de commencer a affirmer que l'implémentation SQL
> > qui est en faite viole des règles de conception !!!
> >
> > A +
> >
> > News Groups a écrit:
> > > Bonjour,
> > >
> > > Je constate que SQL Server permet comme Access de créer des clefs
> externes
> > > composées d'un (ou
> > > plusieurs) champ(s) sans que celui-ci (ou ceux-ci) ne soi(en)t
> affecté(s)
> > > obligatoirement d'une contrainte de null interdit (propriété "Null
> Interdit"
> > > du champ positionnée à "Non"). Ce qui à pour conséquence d'avoir


dans
la
> > > table des valeurs nulles au niveau du champ composant la clef


externe
> (la
> > > clef primaire correspondante n'ayant aucune valeur nulle bien
entendu!)
> .
> > > Ceci étant possible par le choix des options de mise à jour en


cascade
> et à
> > > l'aide de déclencheurs ou procédures stockées.
> > >
> > > exemple de jeu d'enregistrements :
> > > - Table [VILLE] comportant la clef primaire NomDeVille dont les
valeurs
> sont
> > > :
> > > NomDeVille
> > > -------------
> > > Paris
> > > Lyon
> > > Toulouse
> > >
> > > -Table [ADRESSE] comportant la clef externe Ville correspondant à la
> clef
> > > primaire Nom DeVille de la
> > > table [VILLE] (relation 1 à plusieurs entre [VILLE] et [ADRESSE])


:
> > > Nom Ville
> > > ------ ------
> > > Durand Paris
> > > Dupont Lyon
> > > John
> > > Smith Paris
> > >
> > > - L'enregistrement n°3 a une valeur nulle pour le champ Ville !
> > >
> > > Ma question est donc : comment cela est il possible si ce n'est que
SQL
> > > Server ne
> > > respecte pas totalement le concept d'intégrité référentielle, de


clef
> > > primaire et externe ??...
> > >
> > > Est ce le cas d'autre SGBDR : je sais que MySQL ne l'autorise pas,
> Access
> > > oui !, qu'en est -il pour Oracle ou autre SGBDR. ?!
> > >
> > > Si quelqu'un a les réponses, je serais curieux de savoir,
> > > Merci à tous.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
> > Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
> > Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
> > ****************** mailto: ******************
> >
>
>



Avatar
Fred BROUARD
re bonjour,

News Groups a écrit:
Merci de ta réaction, un peut d'humilité de temps en temps ne fait pas de
mal!..



Sans vouloir me défendre, je dirais que mon message permettait de prêcher le
faux pour connaître le vrai : ta réponse à permis de mettre d'accord
l'ensemble des personnes qui ont pris part à la discussion sur le sujet et
qui ne concevais pas la relation 0 à n !! (une copie des pages Web mis en
référence dans ton mail leur à été distribuées...).

Une nota plus générale tout de même sur le sens de la valeur nulle : elle
peut signifier qu'une valeur est à associer mais inconnu à l'instant t ou
bien qu'il n'y a aucune valeur à indiquer, ex : une table composée de
Nom/Prenom/Second_Prenom, le champ Second_Prenom peut être null parce qu'il
n'est pas connu ou bien parce qu'il n'y en a pas. Comment traite tu cette
distinction de sens ?



C'est impossible en l'état de chose actuel de distingue l'un de l'autre.
Certains théoricien des SGBDR aimerait disposer de plusieurs marqueur
comme : NULL, UNKNOWN, NOT APPLICABLE.
A lire :
http://sqlpro.developpez.com/SQL_AZ_2.html#SELECT_NULL

"...l’absence d’information est-elle due à son ignorance ou à son
impertinence ? Pourquoi donc ne pas faire de différence entre la couleur
du toit d’une voiture qui n’est pas connue, et la couleur du toit d’une
moto qui n’est pas applicable… Certains logiciens de l’algèbre
relationnel sont même allés plus loin en proposant différentes valeurs
pour gérer les différents cas, en distinguant des cas très différents :
le « null », le « inconnu » et le « inapplicable »..."

Rien n'empêche de rajouter une colonne pour ce faire.

Quand au fait qu'une clef peut ne pas être connue au moment de
l'insertion mais juste après (insertion dans plusieurs tables avec
intégrité référentielle circulaire) ce cas est géré par la norme SQL à
l'aide de le déférabilité qui permet de valider les contraintes à la fin
de la transaction, et donc d'attendre, par exemple, la fin d'une
procédure stockée afin d'appliquer certaines contrainte d'intégrité.
Ce concept n'est pas géré par SQL Server. Oracle le fait.

A lire aussi :
http://sqlpro.developpez.com/SQL_AZ_E.html#NULL


A +



Merci pour tes réponses (un peu directes tout de même !...mais après tout
cela pousse à acheter ton livre.)



"Fred BROUARD" a écrit dans le message de news:


Visiblement tu ne maitrise pas les problèmes de modélisation...

Contrairement à ce que tu affirme ce comportement est parfaitement
normal. Il dépend du modèle abstrait que tu as donné.
Si relation 0..n alors possibilité de NULL dans la clef étrangère.
Si rlation 1..n alors imposssibilité de NULL dans la clef étrangères,
c'est à dire que chaque colonne comoposant la clef doit être créée avec
la contrainte NOT NULL.

Tes affirmations sur le concept des intégrités référentielles sont des
inepties lamentables.

Sache que SQL (la Norme, pas SQL Server en particulier) va bien au dela
de ce que tu pense.

A lire pour ta culture :
http://sqlpro.developpez.com/SQL_AZ_7b.html#SCHEMA73

Commencent par apprendre ce qu'est un modèle conceptuel de données
(MERISE ou UML) avant de commencer a affirmer que l'implémentation SQL
qui est en faite viole des règles de conception !!!

A +

News Groups a écrit:

Bonjour,

Je constate que SQL Server permet comme Access de créer des clefs





externes

composées d'un (ou
plusieurs) champ(s) sans que celui-ci (ou ceux-ci) ne soi(en)t





affecté(s)

obligatoirement d'une contrainte de null interdit (propriété "Null





Interdit"

du champ positionnée à "Non"). Ce qui à pour conséquence d'avoir dans la
table des valeurs nulles au niveau du champ composant la clef externe





(la

clef primaire correspondante n'ayant aucune valeur nulle bien entendu!)





.

Ceci étant possible par le choix des options de mise à jour en cascade





et à

l'aide de déclencheurs ou procédures stockées.

exemple de jeu d'enregistrements :
- Table [VILLE] comportant la clef primaire NomDeVille dont les valeurs





sont

:
NomDeVille
-------------
Paris
Lyon
Toulouse

-Table [ADRESSE] comportant la clef externe Ville correspondant à la





clef

primaire Nom DeVille de la
table [VILLE] (relation 1 à plusieurs entre [VILLE] et [ADRESSE]) :
Nom Ville
------ ------
Durand Paris
Dupont Lyon
John
Smith Paris

- L'enregistrement n°3 a une valeur nulle pour le champ Ville !

Ma question est donc : comment cela est il possible si ce n'est que SQL
Server ne
respecte pas totalement le concept d'intégrité référentielle, de clef
primaire et externe ??...

Est ce le cas d'autre SGBDR : je sais que MySQL ne l'autorise pas,





Access

oui !, qu'en est -il pour Oracle ou autre SGBDR. ?!

Si quelqu'un a les réponses, je serais curieux de savoir,
Merci à tous.











--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************









--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto: ******************