Discussion :

[korrigan]

Bonjour,

Je dois travailler sur la migration d'une BD non relationnelle Universe sous Oracle. Pour commencer j'aimerais pouvoir modéliser ma base Universe en faisant quelque chose qui ressemble à un MCD mais je ne vois pas trop comment m'y prendre et surtout je ne sais pas si cela à vraiment un sens de vouloir le faire ?

Concrêtement voici un exemple de ce que j'ai à modéliser (cela concerne l'archivage de dossier)

J'ai un fichier dossier avec les attributs suivants :
id_dossier
Liste de dossiers (multivalués un dossier est composé de sous dossiers)
N° archive (un n° pour chaque sous dossier)

et un fichier archive avec les attributs suivants :
id_archive
N° dossier

Je pense avoir une entité dossier et une entité archive mais quid de la notion de sous dossier ? (qui à mon sens reste un dossier et ne me semble pas nécessiter d'entité)

Si quelqu'un peut m'éclairer sur le sujet, je suis preneur...

[TheLeadingEdge]

Bonjour,

Tout dépend de comment tu vois la migration (ou comment on te la fait voir)
1> tu gardes les attributs multi-valués : l'intérêt de faire 1 MCD se limite à de la cosmétique. Ds ce cas fais plutôt 1 DC, au moins tu pourras mapper le contenu des MV comme 1 collection.
2> Soit tu fais ''propre'' et tu normalise tes MV en FN1 : là c'est fortement recommandé de faire 1 MCD.

Par curiosité, si tu gardes la structure actuelle, tu prévoies de faire comment ? Avec des UDT?

Bon courage

[fsmrel]

Bonjour Korrigan

Vous avez l’occasion de produire un modèle conceptuel de données propre : surtout n’hésitez pas ! Vous partez d’un "machin" pour construire un système cohérent dont vous allez définir les fondations. Aujourd’hui le MCD à bâtir est peut-être modeste, mais, si l’occasion se présente, il devra pouvoir évoluer de façon rationnelle harmonieuse, réactive, etc. D’un machin de faites pas un autre machin.

Donc, ne traduisez surtout pas à l’identique dans une base de données relationnelle ce machin qui répond sans doute à un certain traitement, sans que l’on cherche à voir plus loin.

Bref, estimez la pertinence et la robustesse dans le temps de votre base de données à venir.

Pour bâtir votre MCD, chassez de votre esprit tout ce qui relève du niveau physique (le comment) et concentrez-vous sur le quoi, le pourquoi. Si vous n’êtes pas sûr de la finalité des entités que vous allez dégager, interrogez ceux qui dans votre entreprise savent (informaticiens ou utilisateurs) et ne construisez que lorsque vous êtes sûr de vous. Souvenez-vous de ce qu’écrivait Guillaume d’Ockham (il y a 700 ans !) : « Ne multipliez pas les entités au-delà du nécessaire ».

Autrement dit, vous devez disposer de la définition exacte de ce qu’est un dossier, quelles en sont les propriétés, même chose pour un sous-dossier, une archive. Vous devez être à même d’en justifier l’existence, la finalité. Procédez par l’exemple, à partir de dossiers concrets. Concernant les propriétés N° de dossier, N° d’archive, ne vous focalisez pas dessus, elles sont techniques, de même que pour une entité-type E, on définit une propriété N°_de_E. Les propriétés naturelles sont les seules qui soient sémantiquement importantes.

Un modèle conceptuellement intègre donne lieu à une belle architecture et nos bâtisseurs de cathédrales nous donnent des leçons à ce sujet...

http://www.pbase.com/ericdeparis/image/56267968

Vous avez relevé des relations ambiguës entre objets :

Un dossier est composé de sous-dossiers
Un sous-dossier mentionne une archive
Une archive mentionne un dossier.

Il est impératif que le sens de ces relations soit clarifié très précisément, noir sur blanc. Une archive est-elle uniquement l’image d’un sous-dossier ou bien uniquement l’image d’un dossier, ou bien celle de l’un comme de l’autre ? Il n’est pas dit que ces entités survivent à votre enquête et que d’autres voient le jour. Modélisez aussi en ayant présent à l’esprit la courbe du soleil, chère aux merisiens (voir sur le Nète).

Concernant les propriétés multivaluées. Selon la théorie relationnelle, un attribut d’une table peut prendre une table pour valeur et cette théorie propose les opérateurs permettant de les manipuler (notamment GROUP/UNGROUP pour passer du mono au multivalué et inversement). La théorie attire quand même l’attention sur le fait que l’on complexifie les opérations : Un Insert peut en fait avoir à être à remplacé par un Update, etc. Avant d’être un crack de la modélisation et de l’algèbre relationnelle, commencez par modéliser des propriétés monovaluées.

[korrigan]

Bonjour,

Tout dépend de comment tu vois la migration (ou comment on te la fait voir)
1> tu gardes les attributs multi-valués : l'intérêt de faire 1 MCD se limite à de la cosmétique. Ds ce cas fais plutôt 1 DC, au moins tu pourras mapper le contenu des MV comme 1 collection.
2> Soit tu fais ''propre'' et tu normalise tes MV en FN1 : là c'est fortement recommandé de faire 1 MCD.

Par curiosité, si tu gardes la structure actuelle, tu prévoies de faire comment ? Avec des UDT?

Bon courage

Excuse moi je n'ai pas saisi le sens des abréviations DC et UDT ?
L'idée c'est de refaire quelque chose de propre sous Oracle donc en se séparant des MV, mais pour l'instant j'essaie déja de comprendre l'existant.

[TheLeadingEdge]

Re,

DC = diagramme des classes (UML).
UDT = type de données défini par l'utilisateur.

Je pense qu'en choisissant de normaliser tu fais bien. Ca va être chaud à court terme, mais tu devrais vite t'y retrouver.
Je n'ai pas voulu t'influencer, parce que je suis 1 peu de parti pris sur ce sujet.
migration **CK_SYSTEM vers SGBDr j'ai déjà donné. Le MV c'est plutôt séduisant comme concept, mais pas qd la base est gérée par des gros gorets.

A +