avoir un modèle de base agnostique

Bonjour,
Je travaille sur base de standard de donnée pour diffusion nationale.
J'utilise looping, ne suis pas un spécialiste modélisation, et j'aurais sans doute plein de question.
La première, notre base doit être agnostique car compatible : sqlite, postgresql, oracle pour le principaux mais pas que.

Nous avons pas mal de classe d'entité communes à plusieurs autres classes d'entités,
pour les modèles de fichiers sql, les fonction INHERIT de Postgresql aurait été idéale, mais pas compatible avec tous.

Comment faire que le modèle soit le plus universel possible, sur les relations, ou même les nommage ?
Merci

Au passage, si des étudiants en BDD veulent un projet de fin d'année, on a un gros sujet pour eux (mais pas d'argent :D).

Bonjour Pasq2al et bienvenue dans ce forum.

Au niveau conceptuel, la BDD n'a aucune importance, le modèle pourra être utilisé pour tous les SGBD.
Mais dès qu'on décline le modèle conceptuel en modèle tabulaire, le DDL produit par l'outil de modélisation est contraint de s'adapter au choix du SGBD.
En effet, la syntaxe de chaque idiome du langage SQL est différente, le DDL de postgre, n'est pas celui de SQL server, etc.
De plus, certains SGBD gèrent mal les contraintes.

Cela étant dit, avec les bons outils de modélisation, il suffit de changer le nom du SGBD pour que le script DDL produit s'adapte automatiquement au nouveau choix ;)

Par contre, au delà du script (DDL) de création de la BDD, les ordres SQL en général sont assez différents d'un SGBD à l'autre (en particulier les fonctions date et les fonctions chaînes de caractères).

Citation:

---

Envoyé par pasq2al

Nous avons pas mal de classe d'entité communes à plusieurs autres classes d'entités,
pour les modèles de fichiers sql, les fonction INHERIT de Postgresql aurait été idéale, mais pas compatible avec tous.

---

D'une manière générale, la façon de traiter l'héritage dans un MCD est la suivante :
1) Règles de gestion
R1 : Une voiture est un véhicule et un véhicule peut être une voiture.
R2 : Un camion est un véhicule et un véhicule peut être un camion.

2) MCD
Voiture -(1,1)---Etre---0,1- Vehicule
Camion -(1,1)---Etre---0,1----|

Les cardinalités entre parenthèses indiquent une identification relative : l'identifiant de la voiture ou du camion sera celui du véhicule.

3) Tables
te_vehicule_vhi (vhi_id, vhi_immatriculation, [autres colonnes communes à tous les véhicules])
th_voiture_vtr (vtr_id_vehicule, vtr_nb_places, [autres colonnes spécifiques aux voitures])
th_camion_cam (cam_id_vehicule, cam_tonnage, [autres colonnes spécifiques aux camions])

Les clés primaires, soulignées, des tables des voitures et des camions sont aussi clés étrangères (en italique) référençant la table mère des véhicules.

Bonjour,

Je dirais plutôt que l'héritage se modélise soit par la spécialisation, soit par la généralisation, mais que dans les deux cas, il n'y a pas d'association entre le sur type et le sous-type

Si l'on devait utiliser des associations, alors l'identification relative seule ne suffit pas, il faut compléter l'identifiant hérité du sur-type pour composer la PK du sous-type. Sans quoi, le MLD est incomplet.
De plus, dans ce modèle, une contrainte s'impose pour matérialiser le fait qu'un véhicule est soit une voiture, soit un camion, mais pas les deux simultanément.


Voici la différence entre les deux modèles

Pièce jointe 643836

Et les MLD correspondants :

Pièce jointe 643837

Dans le modèle de droite, les tables voiture_1 et camion_1 n'ont pas besoin de complément à l'identifiant hérité de vehicule_1.


EDIT dans le modèle de gauche, j'aurais du utiliser une contrainte de partition (notée XT), sans quoi certains véhicules ne sont ni des camions ni des voitures (pourquoi pas, mais en ce cas on n'est pas iso avec le modèle de droite).

C'est évidemment le second modèle qui est le bon pour l'héritage mais celui-ci s'exprime en règle de gestion avec le verbe être et, dans ma représentation textuelle du MCD, ça donne fatalement 2 pseudo associations "etre".
Avec un héritage, un identifiant propre à l'entité fille (veh_seq, cam_seq) est inutile.

Bonjour,
Le premier modèle ne correspond pas à l'héritage traduit sous forme d'associations : les cardinalités côté classe mère doivent être 0,1 et non 0,n.
De plus, dans le cas d'une spécialisation, il n'y a pas d'identifiant dans les classes filles (contrairement à la généralisation).
Voici ce que cela donne :
Pièce jointe 643873
Et le MLD est alors strictement équivalent à celui issu du modèle avec héritage.

Oui pour le 0,n c'est une coquille de ma part !
Et la contrainte reste (XT) si l'on veut être iso avec le modèle utilisant l'héritage ;)