http://www.academia.edu/586956/Essai_de_comparaison_des_ontologies_informatiques_et_ph ilosophiques_entre_etre_et_artefacts
1 : Clé primaire simple : les « tables d’objets » et les « tables de types » Exemples
1 : Les employés et les départements.
2 : Les livres de la bibliothèque.
3 : Les avions et leurs types
Solutions
Employés (NE, nom, fonction, salaire, #ND) Départements (ND, nom, ville)
Livres (NL, éditeur, dateAchat, #NO) Oeuvres (NO, titre, auteur, dateCréation)
Avions (NA, année, couleur, propriétaire, #typeAvion) TypeAvion(typeAvion, nombre places, année, moteur)
Principe de la distinction entre « table d’objets » et « table de types »
En général, une table avec une clé primaire simple correspond à une réalité physique : les employés, les départements, les exemplaires physiques des livres. Ce sont les « table d’objets ».
On peut aussi les considérer comme des tables d’instance (en référence à la notion d’instanciation de la programmation objet).
Une table avec une clé primaire simple peut aussi correspondre à des types de la réalité physique : c’est le cas des « TypeAvion », par exemple, le A320, ou des « œuvres » qui peuvent être considérées comme un type de « livres », le livre comme l’avion étant les exemplaires physiques (tous les « Voyage au bout de la nuit » de « Louis Ferdinand CELINE »). Ce sont les
« tables de types »
2 : Clé primaire simple et étrangère : les « tables-espèce » et les « tables de compléments » Exemple 1
On gère des personnes. Certaines sont étudiantes et suivent des études : année, domaine, spécialisation. D’autres sont salariés et ont une fonction, un salaire et une date d’embauche.
Solution 1
Personnes (NP, nom, prénom, adresse, téléphone) Etudiants (#NP, domaine, spécialisation, année) Salariés (#NP, fonction, salaire, datemb)
Exemple 2
Une galerie d’art vend des tableaux qui ont un titre, une année de création, une technique, un format, un prix et un auteur. Les tableaux sont des pièces uniques. Ils sont vendus une seule fois à un des clients. On enregistre aussi le prix et la date de la vente. Les clients ont un nom et une adresse
Solution 2
Tableaux (NT, titre, année, technique, format, prix, auteur) Ventes (#NT, prix, date, #NC)
Clients (NC, nom, adresse)
Principe
Une table avec une clé primaire simple et clé étrangère en même temps peut être :
Ø Soit une « table-espèce » (les étudiants)
Elle correspond à une spécialisation d’une autre table (les personnes qui correspondent alors au genre de l’espèce des étudiants). La clé primaire de la « table-espèce » est constituée par celle de la table qu’elle spécialise et est donc clé étrangère en même temps. Un étudiant est caractérisé par les données de son tuple dans la « table-espèce » et les données du tuple référencé dans la table correspondant à son genre, les personnes ici.
On dit que chaque tuple de la « espèce » « hérite » des attributs du tuple de la « table-genre » auquel il fait référence.
Ø Soit une « table de compléments »
Elle ajoute des informations à sa table d’origine : ici, la vente vient compléter les informations du tableau. La vente est un historique du tableau : la table « Ventes » contient une date. Mais la date ne participe pas à la clé primaire car un tableau n’est vendu qu’une seule fois.
L’intérêt de ne pas fusionner les « tables de compléments » avec leurs table d’origine, c’est de garantir la cohérence des données : en effet dans l’exemple proposé, on peut considérer que tous les attributs de la vente sont obligatoires, ce qui ne serait pas gérable en fusionnant la table des ventes et la table des tableaux (on pourrait avoir le NC renseigné mais pas de prix et pas de date). La table de compléments peut donc être considérée comme une « table des attributs facultatifs (pas obligatoires) liés entre eux ». Dans l’exemple, le prix, la date et le numéro de clients ne sont pas obligatoires pour une œuvre (ils ne seront renseignés qu’à l’occasion de la vente), mais sont liés entre eux : si on en renseigne un, il faut renseigner les autres.
3 : Clé primaire concaténée avec un identifiant relatif : les « tables de composants » Exemple
On gère des projets qui ont un nom, une date de début, une date de fin et un budget. Les projets sont composés d’étapes en nombres variables. Une étape est définie par son numéro d’ordre dans le projet (de 1 à N), par une date de début et une date de fin, un nom d’étape et un budget d’étape.
Solution
Projets (NP, nom, début, fin, budget) Etapes (#NP, NE, nom, début, fin, budget)
Principe
Le numéro d’étape est un identifiant relatif : de 1 à N. Il y a plusieurs étapes qui ont le même numéro d’étape. C’est le couple «NP, NE » qui est unique.
L’étape est un composant du projet : elle disparaît nécessairement avec le projet (elle n’a pas d’existence indépendamment du projet).
La table « Etapes » est une « table de composants ». La suppression d’un tuple dans la « table-composé » correspondante (les projets ici) implique nécessairement la suppression des tuples de la « table de composants ».
A noter que l’identifiant relatif peut être un numéro ou n’importe quelle information.
4 : Clé primaire concaténée avec une date : les « tables d’historiques » Exemple
1 : les emprunts à la bibliothèque.
2 : l’historique des adresses des adhérents de la bibliothèque
Solution
Livres (NL, éditeur, dateAchat, #NO) Oeuvres (NO, titre, auteur, dateCréation) Adhérents (NA, nom)
Emprunter (#NL, datEmp, dureeMax, dateRet, #NA) HistoAdressesAdherents (#NA, date, adresse)
Principe
Dès qu’une clé primaire contient une date, c’est un historique.
Dans le cas de l’adresse, on a sorti l’attribut adresse de la table « Adhérents ».
Remarque : historique et historique unique
L’exemple de l’historique unique concerne des tableaux qui sont vendus une seule fois : Ventes (#NT, prix, date, #NC)
La table « Ventes » est ici une « table de compléments ».
Si les tableaux pouvaient être vendus plusieurs fois (imaginons une location pour une certaine durée), la table d’historique unique deviendrait une table d’historique :
Location (#NT, date, durée, prix, #NC)
5 : Clé primaire concaténée avec uniquement des clés étrangères : les « tables de liaisons » Exemple 1
Un employé participe à plusieurs projets. Plusieurs employés participent à un projet.
Ø Solution
Employés (NE, nom, dateEmbauche)
Projets (NP, intitulé, dateDébut, dateFin, budget) Participer (#NE, #NP)
Principe
La table « Participer » est une « table de liaisons » entre les employés et les projets.
La clé primaire comporte plusieurs attributs dont au moins une clé étrangère.
Il n’y a pas d’attribut « date » dans la clé primaire.
Il n’y a pas de relation de composition entre les attributs de la clé primaire.
Il peut y avoir des attributs en plus de la clé primaire.
Exemple 2
On ajoute à l’exemple 1 le fait que l’employé joue un rôle unique sur le projet.
Ø Solution
Participer (#NE, #NP, rôle)
Exemple 3
On considère maintenant que l’employé peut jouer plusieurs rôles sur le projet et que pour chaque rôle de l’employé sur le projet on définit le nombre de jours d’activité.
Ø Solution
Participer (#NE, #NP, rôle, nbJours)
Principe
Une table de liaisons peut être constituée de plus de 2 attributs.
Les attributs d’une table de liaisons ne sont pas forcément des clés primaires mais ils sont forcément des identifiants.
Dans l’exemple 3, l’attribut « rôle » jour le rôle d’un identifiant : il pourrait être clé primaire de la table des rôles dans laquelle on trouverait par exemple le coût journalier pour un rôle donné.
6 : Table complexe Exemple 1
On gère des projets qui ont un nom, une date de début, une date de fin et un budget. Les projets sont composés d’étapes en nombres variables. Une étape est définie par son numéro d’ordre dans le projet (de 1 à N), par une date de début et une date de fin, un nom d’étape et un budget d’étape.
Le budget des étapes peut varier. On veut garder l’historique.
Solution 1
Projets (NP, nom, début, fin, budget) Etapes (#NP, NE, nom, début, fin)
HistoBudgetEtapes (#(NP, NE), date, budget)
Principe 1
Les clés étrangères peuvent toujours faire référence à n’importe quel type de clé primaire. Elles peuvent donc toujours être concaténées.
Dans l’exemple traité, on un historique : c’est un historique de la table de composition.
La clé étrangère de la table d’historique fait référence à une clé primaire concaténée.
Exemple 2
On envoie des courriers en nombre à des clients. Un courrier est caractérisé par un libellé et une date. Un même courrier peut être envoyé plusieurs fois à la même personne. On veut savoir quel client à reçu quel courrier
Solution 2
Courriers (NCO, libellé, date) Clients (NCL, nom, adresse) Envoyer (#NCL, #NCO, date)
Principe 3
C’est le même principe qu’un historique simple. C’est un historique de table de liaisons.
La clé étrangère de la table d’historique fait référence à une clé primaire concaténée : une table de liaisons. On pourrait écrire :
HistoEnvoyer (#(NCL, NCO), date) Envoyer (#NCL, #NCO)
Dans notre exemple, il est inutile de séparer les deux tables car la table envoyer ne contient pas d’attribut en dehors de la clé.
Exemple abstrait
On peut imaginer une table de liaisons historique qui relie une table de liaisons historique avec une table de composition, ce qui donnerait comme clé primaire :
#(CP, n°), #(CP1, CP2, date), date
7 : Synthèse
Ontologie relationnelle
On a initialement distingué entre 2 types de tables : celles à clé primaire simple (les « tables-nom ») et celles à clés primaires concaténées (les « tables-verbes »).
On distingue maintenant 5 types de clés primaires : CP, #CP, (#CP, date), (#CP, n°), (#CP1,
#CP2).
Ces 5 types de clé primaire correspondent à la description de 7 types de réalité : c’est la sémantique des tables de l’ontologie relationnelle.
A cela s’ajoute la possibilité de former des tables complexes.
TYPOLOGIE
Table-espèce, table-nom, table-verbe : espèce, nom et verbe au singulier car c’est la table qui est une espèce, un nom ou un verbe et non pas les tuples.
Table d’objets, de types, de composants, de compléments, d’historiques, de liaisons : tous au pluriel car chaque tuple est un objet, un type, un composant, etc., donc il y en a plusieurs par table.
Ø Remarque 1
Les tables de liaisons peuvent avoir plus de 2 clés étrangères.
Ø Remarque 2
Dans une table de liaisons, un attribut de la clé primaire peut, tout en étant un identifiant absolu (et non pas relatif), ne pas être clé étrangère. On peut donc avoir des tables de liaisons de la forme : #CP1, attribut.
Ø Remarque 3
Les tables d’historiques peuvent être des « tables-noms » ou des « tables-verbes ». L’historique d’un attribut est une « table-nom » : (#NEmployé, date, salaire). L’historique des emprunts de livres est une « verbe » : (#NLivre, dateEmp, dateRetour, #NAdhérent). C’est une « table-verbe » car elle relie les livres et les adhérents.
Ø Remarque 4