Discussion :

[Nerva]

Bjr.

J'ai une question con à poser... Dans une table, et plus globalement en SQL, comment appelle-t-on officiellement l'intersection d'une colonne et d'une ligne, ce que l'on nomme une cellule dans un tableur ?

Merci.

[tatayo]

Bonjour,
Une colonne, tout simplement.

Tatayo

[SQLpro]

Plus exactement la valeur d'un attribut d'un relvar (rel : relationnel, var : variable, donc l'ensemble des valeurs d'une ligne)... Mais ce terme est hélas rarement employé sauf par les professionnels !

A +

[Nerva]

relvar, j'avais déjà vu ce terme dans une documentation (sur la normalisation il me semble, et quoi qu'il en soit, difficile à appréhender à mon niveau) sans comprendre exactement ce qu'il définissait.

Merci.

[tatayo]

relvar... au bureau ça parle de "champ" et de "record" , alors si je commence à parler relvar c'est la fin du monde.

Tatayo.

[Nerva]

relvar... au bureau ça parle de "champ" et de "record" , alors si je commence à parler relvar c'est la fin du monde.

Sans oublier les tuples et les n-uplets...

C'est en partie pour ça que j'ai posé la question. Selon la dénomination Access (et pareil pour LibreOffice Base), un champ c'est une colonne et un enregistrement, une ligne. Pour moi un champ c'est une cellule de formulaire où on saisit une donnée, comme une quantité (ou qui en affiche une, comme un total).

Donc, en termes de communication, faut bien pouvoir nommer les choses correctement pour se faire comprendre, non ?

[escartefigue]

La particularité d'Access c'est que c'est non seulement un SGBD (très médiocre, certes, mais simple d'accès) mais aussi une IHM avec des formulaires.
Or les champs des formulaires possèdent les même noms que les colonnes des tables sous jacentes, c'est la raison pour laquelle Access confond allègrement "champ" et "colonne", mais, ce sont bien deux choses très différentes.

Dans une table, on parle de lignes et de colonnes, et pour une occurrence particulière d'une intersection ligne/colonne, alors c'est une valeur d'attribut.

Attention : la "RelVar" (Variable Relationnelle) n'est pas une intersection ligne/colonne, la RelVar est une table.

Voyez l'excellent article de FsmRel à ce sujet ICI

[SQLpro]

Le terme champ s'applique à un domaine purement visuel.... Champ de patate pour le paysan, Champ visuel pour l'ophtalmo. Champs opératoire du chirurgien.... En informatique c'est une zone de saisie..... Rien à voir avec les bases de données relationnelles ni les tables, puisqu'il n'existe aucune possibilité de saisie dans un SGBDR, juste la possibilité d'envoyer des requêtes et d'attendre un résultat :

• soit jeux de données (en anglais dataset) lors d'un SELECT
• soit un code de retour (information, avertissement, exception) pour toutes les autres opérations

Au niveau de la conception des modèles de données (modeèle conceptuel) on utilise les termes suivants :
Entité, attribut, association, clés
Au niveau purement mathématique (modèle logique) on parle de :
Relations, attributs, clés (étrangères, primaires...)
Au niveau de l'implémentation dans un SGBDR (modèle physique), on utilise :
Table ou vue, colonnes, lignes, contraintes, ...

Il manque effectivement un terme pour désigner les valeurs d'un tuple (nom anglo-saxon) ou n-uplet (français), c'est à dire l'nsmble des valeurs que porte chaque colonne d'une ligne.... Le terme RELVAR voulant dire RELational VARiable a été proposé, mais jamais entériné par une quelconque norme (le langage SQL est normalisé depuis 1982...). On devrait donc dire valeur de la colonne machin d'un RELVAR...

Pourtant la distinction est bien faite dans les langages informatiques ou l'un a un terme pour le contenant (la variable) et un autre pour le contenu (la valeur)....

Je sais, c'est difficile mais la confusion terminologique à ce niveau entraine souvent des incompréhensions...

Pourtant je ne cesse d'alerter sur ce problème :
https://sqlpro.developpez.com/cours/sqlaz/erreurs/#L2

A +


A +

[Nerva]

Or les champs des formulaires possèdent les même noms que les colonnes des tables sous jacentes, c'est la raison pour laquelle Access confond allègrement "champ" et "colonne", mais, ce sont bien deux choses très différentes.

Les champs de formulaire ont le nom qu'on leur donne, mais c'est vrai qu'Access (que je n'utilise plus depuis longtemps) et LibreOffice Base donnent par défaut aux champs le nom de la colonne de la table correspondante lors de la création (que ce soit par l'assistant ou en manuel). Après mieux vaut les renommer pour s'y retrouver facilement, notamment dans le code Basic.

Colonne de table : CLI_PRENOM
Champ de formulaire : txtCliPrenom

Après ça reste difficile d'expliquer la différence à des utilisateurs novices étant donné que la terminologie interne du logiciel (Access à déteint sur LO Base) est basée sur les termes "champ" et "enregistrement", comme le sélecteur de lignes, qui affiche "enregistrement suivant, précédent..." ou une boîte de dialogue qui vous dit : "Vous avez l'intention de supprimer 1 enregistrement, etc..."

[escartefigue]

Le problème c'est qu'Access, dans sa propre documentation, parle de "champs" de tables au lieu de "colonnes", c'est là que le bât blesse.
Je ne sais pas ce qu'il en est de libre office base, que je n'ai jamais utilisé.

[fsmrel]

Bonsoir,

Dans une table, et plus globalement en SQL, comment appelle-t-on officiellement l'intersection d'une colonne et d'une ligne, ce que l'on nomme une cellule dans un tableur ?

 
Je ne sache pas qu’il existe un terme officiel, mais si vous utilisez le terme pertinent de cellule, personne ne pourra vous le reprocher, au contraire...
 
 

relvar, j'avais déjà vu ce terme dans une documentation (sur la normalisation il me semble, et quoi qu'il en soit, difficile à appréhender à mon niveau) sans comprendre exactement ce qu'il définissait.

 
Vous avez probablement parcouru cet article :
Bases de données relationnelles et normalisation : de la première à la sixième forme normale, lequel, je le reconnais n’est pas toujours facile à appréhender...
 
 

Au niveau de la conception des modèles de données (modèle conceptuel) on utilise les termes suivants :
Entité, attribut, association, clés

 
Attention, au stade MCD, une entité est une instance d’une entité-type (synonymes : type d’entité, classe d’entités). Les clés sont du niveau MLD et SQL. Au stade MCD, une entité-type possède non pas une clé, mais un identifiant.
 
 

Le terme RELVAR voulant dire RELational VARiable a été proposé, mais jamais entériné par une quelconque norme (le langage SQL est normalisé depuis 1982...).

 
Par définition, dans le contexte du Modèle Relationnel de Données (théorie relationnelle), une relvar est une variable prenant des valeurs qui sont des relations.

Le terme relvar a été initialement défini par C. J. Date et Hugh Darwen dans un article paru dans Database Programming & Design 8, No. 1 (January 1995). Les auteurs ont voulu clarifier la différence entre variable (relvar) et valeur (relation).

Fred, tu as tout compris et rejoins Date et Darwen quand tu écris :

« la distinction est bien faite dans les langages informatiques ou l'un a un terme pour le contenant (la variable) et un autre pour le contenu (la valeur)... »

SQL utilise le même terme pour la variable et la valeur. Pour aller dans ton sens, je dirais que la contrepartie SQL de la relvar est la table considérée comme variable (je pense que l’instruction CREATE TABLE aurait pu s’écrire DECLARE TABLE), ou comme valeur, quand par exemple lorsque je code « UPDATE T », je remplace (conceptuellement du moins) une valeur de T par une autre valeur.

Incidemment, la norme SQL ne date pas (officiellement) de 1982 mais de 1986 (coquille ?)

[SQLpro]

...

Incidemment, la norme SQL ne date pas (officiellement) de 1982 mais de 1986 (coquille ?)

Oui tu as raison.... Mae culpa ! (je sais pas qui c'est Maé.... mais bon, elle en prend pour son grade la petite... !)

Autre chose, si la table est bien le conteneur, alors je jeu de données est donc le contenu...

Le tuple ou n-uplet l'ensemble des valeurs de toute les colonnes d'une ligne.

Mais la valeur de l'intersection ligne colonne.... on la nomme comment ? valeur ???

A +

[Nerva]

Vous avez probablement parcouru cet article :
Bases de données relationnelles et normalisation : de la première à la sixième forme normale, lequel, je le reconnais n’est pas toujours facile à appréhender...

C'est ça...

Oui tu as raison.... Mae culpa ! (je sais pas qui c'est Maé.... mais bon, elle en prend pour son grade la petite... !)Mais la valeur de l'intersection ligne colonne.... on la nomme comment ? valeur ???

Oui mais si le contenu est NULL, ce n'est pas une valeur ?

[fsmrel]

Bonjour,

Oui mais si le contenu est NULL, ce n'est pas une valeur ?

 
Dans Database Design and Relational Theory, page 69, C. J. Date pose la question :

Que signifie-t-il pour une table d’être une représentation directe et fidèle d’une relvar ? Il précise : la réponse à cette question implique les cinq conditions ci-dessous qu’une valeur de table doit respecter (pour être une valeur de relvar c’est-à-dire une relation) :
 
1. Pas de lignes en double.
2. Les colonnes ne doivent pas être ordonnées (disons de gauche à droite).
3. Les lignes n’ont pas à être ordonnées (disons de haut en bas).
4. Chaque colonne porte un nom et ce nom est unique pour chaque valeur de table.
5. L’intersection d’une ligne et d’une colonne doit contenir exactement une valeur du type (domaine) applicable et rien d’autre : pas de colonnes cachées (hidden columns), pas de "row IDs", pas de timestamps cachés (cf. An Over view and Analysis of Proposals Based on the TSQL2 Approach). Et bien entendu le marqueur, le bonhomme NULL n’étant pas une valeur du type applicable, il est de facto hors la loi !

Incidemment il va de soi que ces cinq points sont à respecter pour qu’une valeur de table soit en 1NF (première forme normale)...

[SQLpro]

Une question néanmoins se pose au sujet du marqueur NULL.... Pour information, si je fais un :

Code :

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

SELECT NULL AS COLONNE

Quel est le type de cette colonne !

A +

[tatayo]

Comme il n'y a pas de valeur, je dirais que cette colonne n'a pas de type.

Tatayo

[fsmrel]

Une question néanmoins se pose au sujet du marqueur NULL.... Pour information, si je fais un :

Code :

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

SELECT NULL AS COLONNE

Quel est le type de cette colonne !

Comme dit tatayo, « cette colonne n’a pas de type ». NULL reste un marqueur.
On n’est pas dans le cadre du Modèle Relationnel de Données, le bonhomme NULL y est pour toujours hors la loi.