Base de données object et Membres composites

Bonjour,

Pour un projet en base de données orientée objet, nous devons mettre en place des types personnalisés (comme des classes).
A la base, nous étudions cela sous Oracle qui nous permet de faire pratiquement tout ce qu'on veut en objet mais pour des raisons pratiques, nous ne pouvons utiliser que postgreSQL (c'est déjà très bien mais on sait rien sur le sujet).

Voici notre modèle de base:
Concept : Contient un membre vedette
Terme: Type abstrait
Vedette: Hérite de Terme
Synonyme: Hérite de Terme et contient un membre vedette.

Pour représenter cela en postgreSQL, nous avons créé les tables car il ne semble pas permettre qu'on puisse créer des types abstrait et héritable.
Cependant, pour chaque table créée, il créé le type composite associé.
Cela semblait être un bon compromis mais il semblerait que les membres composites (par exemple vedette dans Concept) ne soient pas concrètement liés à la table vedette.
n'y a t il pas un moyen de l'obliger ? N'y a t il pas un autre modèle possible que vous pourriez me proposer ?
J'ai vu qu'il existait des OID qui fonctionnerait comme des pointeurs (mais en fait ce sont des sortes de clés primaires), suis je obligé de les utiliser pour composer mes type entre eux ?! Car là, on commence à vachement dériver du sujet initial alors ça nous embête un peu.

EDIT: A la base, j'ai posté dans cette partie car je voulais savoir comment faire un INSERT et un UPDATE sur des types composites liés à d'autres tables.

Merci de m'avoir lu.

bonjour,

PostgreSql gère une sorte d'héritage, via l'inheritence.
http://www.postgresql.org/docs/9.1/s...l-inherit.html

Mais perso je trouve que gérer ceci via trigger / vue est beaucoup plus simple (en particulier à cause du fait que les données ne sont pas propagée entre les tables..)


que veux dire ceci ?

Citation:

---

Cela semblait être un bon compromis mais il semblerait que les membres composites (par exemple vedette dans Concept) ne soient pas concrètement liés à la table vedette.

---

Pouvez-vous expliquer un peu mieux votre problème actuel avec un exemple concret ? (la définition des tables serai un bon début)


edit : question subsidiaire : pourquoi vouloir faire de l'object-relationnal avec pgsql ? Surtout si vous comptez créer des tables qui contiennent des array .. c'est se tirer un peu une balle dans le pied pour pas grand chose non ?

http://asktom.oracle.com/pls/asktom/...:1545206281987 (article un peu vieux mais discussion intéressante sur l'approche objet-relationnel)

D'abord, merci de ta réponse.

Citation:

---

Envoyé par punkoff

PostgreSql gère une sorte d'héritage, via l'inheritence.
http://www.postgresql.org/docs/9.1/s...l-inherit.html

---

Ca c'est bon, on l'utilise, c'est pas super terrible m'enfin, c'est surtout au niveau de la composition qu'on a un soucis.

Citation:

---

Envoyé par punkoff

Mais perso je trouve que gérer ceci via trigger / vue est beaucoup plus simple (en particulier à cause du fait que les données ne sont pas propagée entre les tables..)

---

Ca fait partie des contraintes.

Citation:

---

Envoyé par punkoff

que veux dire ceci ?

---

Si j'ai ved (de type vedette) membre composite de concept et que vedette est un type créé par la table du même nom, ceci n'est pas un pointeur vers une entrée de la table vedette mais bel et bien un objet à part.
Il faudrait que ce soit un pointeur vers un objet vedette, un vrai ! (appartenant à la table vedette)

Citation:

---

Envoyé par punkoff

Pouvez-vous expliquer un peu mieux votre problème actuel avec un exemple concret ? (la définition des tables serai un bon début)

---

Mes tables (et types):
Concept:
- vedette : vedette

Terme:
- libelle : varchar(30)

Vedette (Hérite de Terme):
- dataAjout : Date

Synonyme (Hérite de Terme):
- vedette : vedette

J'ai enlevé les champs annexes donc du coup, ça change pas beaucoup de ce que j'avais déjà donné ;)

Citation:

---

Envoyé par punkoff

edit : question subsidiaire : pourquoi vouloir faire de l'object-relationnal avec pgsql ? Surtout si vous comptez créer des tables qui contiennent des array .. c'est se tirer un peu une balle dans le pied pour pas grand chose non ?

---

Parce que c'est un projet d'objet-relationnel et de ce qu'on en sait, il n'y a normalement qu'Oracle et pgsql qui le permettent, or Oracle est payant donc il reste que pgsql (de plus c'est intéressant d'apprendre le pgsql en sachant que c'est l'un des plus performants).
enfin, il n'est nullement question d'utiliser des tableaux, varray, nested table ou autres, juste des pointeurs vers des entrées d'une autre table.
Mais apparemment, je vais devoir jouer avec les OID et faire passer ça pour des pointeurs.

Citation:

---

Parce que c'est un projet d'objet-relationnel et de ce qu'on en sait, il n'y a normalement qu'Oracle et pgsql qui le permettent, or Oracle est payant donc il reste que pgsql

---

C'est discutable.
Si c'est un projet à but éducatif, il n'est pas nécessaire d'acheter des licences, vous pouvez utiliser Oracle XE (Express Edition).
Côté postgresql, à part l'héritage de table, il n'y a pas d'autre fonctionnalité objet, si bien que le qualifier de SGBD objet est abusif.
A mon avis c'est un malentendu d'origine historique. Au départ il y avait une potentialité objet, d'où l'existence des OIDs et le qualificatif d' "objet-relationnel". Mais ce potentiel n'a finalement pas été développé.

C'est assez dommage, je vais voir ce que veulent les profs et on s'orientera soit vers les OIDs, soit vers Oracle (d'une manière ou d'une autre).