Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je suis en stage et je dois faire une base de données. Pour une des tables, je dois mettre : règne, familles, genre, espèce. L'espèce dépend du genre qui dépend de la famille qui dépend du règne. Cependant je peux mettre une espèce qui appartient à une famille sans connaître le genre.
On m'a dit que cette table doit être en auto-référencement aussi appelé table hiérarchique mais je ne sait comment faire. Pourriez-vous m'aidez?
Hors ligne
xxxxx lien supprimé, voir commentaire xxxxx
bien à vous
Hors ligne
Je ne modifie jamais les commentaires des utilisateurs du forum mais là, je me sens obligé de le faire (le lien remplacé par le texte "xxxxx lien supprimé, voir commentaire xxxxx", c'est moi).
À ma connaissance, le livre de Joe Celko, "Trees and hierarchies in SQL for smarties", n'est pas un livre dans le domaine public, et il n'est donc pas librement partageable. Si je me trompe, merci de me le dire et on rétablira le lien. Si j'ai raison, merci d'éviter ce genre de choses à l'avenir.
Guillaume.
Hors ligne
Des CTEs récursives sur des tables autoréférentielles : http://www.postgresonline.com/journal/a … tures.html
Ou alors ltree : https://www.postgresql.org/docs/9.2/static/ltree.html
Hors ligne
Bonjour Michel,
j'aurais plutot tendance à faire des tables differentes qu'une seule table auto référencée.
vous pouvez creer des contraintes referentielles entre ces tables pour vous assurer que vos données existent bien dans chaque catégorie.
Ajouter un règne, famille ou genre 'INCONNU' par exemple sur lequelle vous pourrez pointer.
règne, familles, genre, espèce
ex:
table regne (regne_id, regne_nom): (1, animal) (2, vegetal) (3,inconnu)
table famille (fam_id, regne_id, nom_fam): (1,1,vertébrés), (1,3,martien) la deuxieme famille étant d'un regne inconnu mais la contrainte referentielle étant respectée.
si l'objectif est de creer des contraintes afin d'éviter de rentrer des informations inexactes cette solution me semble plus sure.
Si vous tenez surtout à une représentation des données plus proche de l'arbre. les liens que vous avez envoyés sont interessants.
Je ne sais pas si il sera simple d'y integrer des "trous" dans les informations, ca me semble compliqué dans le deuxième cas.
Demis
Hors ligne
Effectivement, votre système a l'avantage d'être fidèle au modèle relationnel comme je l'avais écrit dans une vie précédente :
We changed the data structure for the implementation of Adjacency List Model for trees with relational operators.
Instead of
tree(node_id, node_up_id, topic)
where node_up_id is a reference (FK) to node_id
we use a two-tables representation of a tree :
nodes(node_id, topic)
edges(from_node, to_node)
where from_node and to_node are references (FKs) to nodes.node_id
It’s always better to use normalized data model.
It takes often a bit of effort but the queries will be easier to design.
We implement in PostgreSQL this model :
create sequence node_sequence;
create table nodes (
node_id integer not null
default nextval('node_sequence')
primary key
,topic varchar(128)
);
create table edges (
from_node integer not null
references nodes(node_id)
on update cascade
,to_node integer not null
references nodes(node_id)
check (from_node != to_node)
,primary key(from_node, to_node)
);
Hors ligne
Pages : 1