Objet-relationnel standard SQL3

Bonjour les professionnels un petit coup de pouce pour un étudiant svp !

mon problème c'est que je veux ajouter une liste de type LIST(Category_t) dans la colonne categories de la table Dim_Film. mais oracle me donne une erreur je pense que oracle n’implémente pas toutes les fonctionnalités de sql3.
je cherche un solution pour contourner ce problème voila mes instructions : .

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

Create type Category_t as object ( name varchar(25) );     Create type Actor_t as object ( first_name varchar(45), last_name varchar(45) );     chaque film appartient a plusieurs catégories et plusieurs acteurs participant au film.   Create type Film_t as object ( idFilm number, title varchar(255), Actors LIST(Actor_t), // norme SQL3 categories LIST(Category_t) // norme SQL3 );   Create table Dim_Film of Film_t ( constraint pk_Film primary key (idFilm) );

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 Connected as mni   SQL> SQL> CREATE type Category_t AS object ( 2 name varchar(25) 3 ) 4 /   Type created SQL> CREATE type Actor_t AS object ( 2 first_name varchar(45), 3 last_name varchar(45) 4 ) 5 /   Type created SQL> create type Category_nt_t As Table Of Category_t 2 /   Type created SQL> create type Actor_nt_t As Table Of Actor_t 2 /   Type created SQL> REM chaque film appartient a plusieurs catégories SQL> REM et plusieurs acteurs participant au film. SQL> CREATE type Film_t AS object ( 2 idFilm number, 3 title varchar(255), 4 Actors Actor_nt_t, 5 categories Category_nt_t 6 ) 7 /   Type created SQL> CREATE TABLE Dim_Film of Film_t (idFilm PRIMARY KEY) 2 OBJECT IDENTIFIER IS PRIMARY KEY 3 NESTED TABLE actors store as act_nt, 4 NESTED TABLE categories store as cat_nt 5 /   Table created   SQL>

---

Avec un modèle de données normalisé, ce serait quand même mieux ! :roll:

Citation:

---

Envoyé par CinePhil

Avec un modèle de données normalisé, ce serait quand même mieux ! :roll:

---

Qu'est-ce que vous trouvez comme n'étant pas normalisé ?
:roll:

Ben justement l'utilisation de types multiples.

MCD :
film -1,n----avoir----0,n- category
|--------1,n----jouer----0,n- acteur

Tables :
film (flm_id, flm_titre...)
category (cat_id, cat_libelle)
acteur (act_id, act_nom, act_prenom...)
flm_avoir_cat (fac_id_film, fac_id_category)
act_jouer_flm (ajf_id_acteur, ajf_id_film)

Etc.

Une bonne modélisation des données est la première étape pour une application performante.

La solution proposée est toute à fait normalisée ! Choisir entre cette solution et la votre dépend fortement de ce que vous allez faire avec vos données: les traitements. Mais, encore une fois, il n’y rien de non normalisé dans cette approche.

Ben si, le type tableau autorisé par SQL3 est une hérésie par rapport aux formes normales, et notamment la première sur l'atomicité des données.

Citation:

---

Envoyé par CinePhil

Ben si, le type tableau autorisé par SQL3 est une hérésie par rapport aux formes normales, et notamment la première sur l'atomicité des données.

---

Je me permets d'entrer dans cette discussion pour rappeler qu'ici il n'est plus question d'une base de données (table) relationnelle mais plutôt d'une table objet contenant desc colonnes du type nested table. Aussi, vous devriez en tenir compte.

Je ne conseillerai nullement à qui que ce soit d'opter pour ce genre de table. En effet, à cause des objects cachés générés par Oracle lors de la création de ce type de table, et sans que vous ne soyez au courant, vous allez vous trouver avec de sérieux problèmes de performance et même de lock et de deadlocks; particulièrement lorsque vous n'indexez pas la contrainte d'intégrité qui existe entre la table et ses nested tables. Et comment vous auriez pu créér cette FK si vous n'êtes pas au courant de son existence?

https://forums.oracle.com/forums/mes...468724#9468724

http://asktom.oracle.com/pls/asktom/...47100346178079

Citation:

---

Envoyé par CinePhil

Ben si, le type tableau autorisé par SQL3 est une hérésie par rapport aux formes normales, et notamment la première sur l'atomicité des données.

---

Vous vous trompez! Lisez Chris J. Date, par example: Database in Depth: Relational Model for Practitioners

Le temps que j'achète le bouquin et que je lise (en anglais en plus !), la discussion sera aux oubliettes !

Cite donc l'extrait qui argumente en ta faveur.

J'aimerais bien que fsmrel fasse un tour par ici pour en débattre car il a bien plus d'expérience que moi en la matière mais il s'est mis un peu en congés du forum ces temps-ci. Je vais quand même lui envoyer un MP.

Pour en avoir fait un peu, je rejoins l'avis de Mohamed.Houri ici.

Une première solution à un problème que j'ai rencontré utilisait des Nested Tables.
Les scripts d'alimentations étaient ma foi assez difficile à écrire et même à comprendre.
Les performances sur des volumétries relativement moyennes étaient à peine acceptables.
Au final la solution était lancée une fois tous les six mois avec douze heures de traitement.

J'ai pu réécrire intégralement ce processus en m'appuyant sur un modèle de données relationnel : les scripts d'alimentations sont simples et les performances de premier ordre.
La couche objet a été intégralement déportée dans des vues. Elle existe toujours mais n'a plus d'impact sur le stockage des données.
La solution tourne toutes les semaines et ne dure plus que vingt minutes (la première re-génération globale a duré un peu moins d'une heure).

C'est bien plus performant et simple à maintenir.

@CinePhil
Ca sera pour ce soir ou ce week-end au plus tard.

@Waldar et @Mohamed
C’est un fil de discussion ouvert par un étudiant qui a du mal à faire ses devoir et non pas une plaidoirie pour une certaine solution.
En dépit de vos objections et de mes réticentes à implémenter une telle solution je vais continuer à dire que ce qui compte est ce qu’on fait avec ces données.
En conclusion, je rappellerais ici la citation que Mohamed à fait il y a quelques jours: "never say always, never say never, I always say" ! :lol:

Vous avez raison ma réponse n'a pas de lien avec le sujet initial.

Je profitais du sujet pour un retour d'expérience plus global, il ne faut pas le voir autrement.

Citation:

---

Envoyé par mnitu

@CinePhil
Ca sera pour ce soir ou ce week-end au plus tard.

---

Pas urgent.

Citation:

---

@Waldar et @Mohamed
C’est un fil de discussion ouvert par un étudiant qui a du mal à faire ses devoir

---

Ce n'est pas l'impression que m'a laissé son message :

Citation:

---

je veux ajouter une liste de type LIST(Category_t)

---

Rien ne dit que c'est pour un devoir et que ce soit la solution qui lui est demandée par un exercice ; à lui de nous le dire.

J'ai plutôt eu l'impression qu'il se précipitait un peu vite sur une solution d'apparente facilité et je faisais remarquer que ce n'était probablement pas la meilleure, ce qui est confirmé par d'autres ayant plus d'expérience que moi en ce domaine.

Ceci dit, si effectivement il s'agit d'un exercice qui lui demande de faire ça et s'il se sent agressé par mes remarques, je lui en demande pardon, ainsi qu'à vous mnitu.

J'ai finalement trouvé le paragraphe: Data Value Atomicity

C. Date va ici d'un extrême (une chaîne de caractères est un ensemble de caractères donc non atomique) à l'autre (toutes les données d'un fournisseur sont une donnée atomique).

Il finit par dire ceci :

Citation:

---

The real point I’m getting at here is that the notion of atomicity has no absolute meaning; it
just depends on what we want to do with the data.

---

Dans une récente discussion, j'ai eu presque les mêmes propos, suite à une question existentielle, du même ordre que les considérations extrèmes de C. Date, que se posait l'auteur de la discussion.
Je répondais notamment ceci :

Citation:

---

Envoyé par CinéPhil

L'atomicité de la donnée dans le modèle relationnel est à comprendre en quelque sorte comme la plus petite donnée présentée à l'utilisateur.
Si celui-ci cherche M. Dupont, il ne va pas chercher d'abord D puis U puis P...
Par contre, s'il cherches toutes les catégories auxquelles appartient un produit, il va finir par lire individuellement chaque nom de catégorie et celles-ci sont bien chacune des données atomiques. Mettre toutes les catégories d'un produit dans une seule colonne de la table produit est une erreur en relationnel.

---

Selon moi, mettre toutes les catégories d'un film dans une colonne de la table film, que ce soit dans une colonne de type textuel avec les catégories séparées par les virgules ou par un l'utilisation d'un type tableau, ce n'est pas une donnée atomique et c'est un viol de la première forme normale.

Du coup, ça ne m'étonne pas que ce soit effectivement peu performant.

J'espère que nous n'embrouillons pas trop Istara avec ces considérations théoriques ; il ne s'est plus manifesté depuis la création de la discussion.

Nous sommes d'accord que nous ne sommes pas d'accord.
Du point de vue du modèle relationnel cet approche est correcte et ne viole rien.
Parler des performances sans avoir la moindre idée de ce qu'on fait avec ces données est largement hasardeux.
Je continue à vous recommander de lire Date et de réfléchir à la question.

Citation:

---

Envoyé par mnitu

Je continue à vous recommander de lire Date et de réfléchir à la question.

---

Idem !

Sujet intéressant et quelque peu perturbant, et je suis plutôt d'accord avec mnitu.

Suite a une discussion avec Oishiiii, j'ai découvert il y a peu qu'une colonne contenant 'Paris,Lille,Marseille' reste valide 1NF et que la seule façon de ne pas l'être était d'accepter des colonnes NULLs.... autant dire qu'en théorie il est impossible d'être non conforme 1NF mais qu'en pratique un grand nombre de tables sont non conformes 1NF....

Donc il est normal que Date considère que la relation R2 (cf lien de mnitu) soit conforme 1NF.

Et d'ailleurs Oishiiii mentionne le lien suivant où fsmrel "approve his message" concernant les RVA

On retrouve là, la modélisation de la relation R3 mentionnée par Date et correspondant au sujet actuel.

Il est important de considérer la différence entre un bon schéma et la 1NF, la 1NF ne garantissant rien !

Je pense que nous sommes tous plutôt d'accord et en faveur d'un modèle relationnel comme celui proposé par cinephil, car mnitu a également bien précisé :

Citation:

---

Envoyé par mnitu

En dépit de vos objections et de mes réticentes à implémenter une telle solution

---

Le débat portant sur la 1NF, je pense que mnitu a raison.

PS1 : Istara, ce débat ne te passionnera peut être pas mais garde à l'esprit que la solution proposée par mnitu correspond a ton besoin si l'objectif est d'avoir 20 à un TP, mais que cette solution présente également de nombreux désagréments comme mentionnés par waldar et mohamed.

PS2 : cinephil, as tu déjà été confronté à l'ineptie du stockage d'un serialize php ?
Argh, je déteste cette fonction, enfin surtout l'utilisation qu'en font les développeurs php !
Mais bon, elle reste conforme 1NF d'après ce que j'ai compris...
Heureusement que la théorie ne s'arrête pas à la 1 NF !

Bonsoir,

Citation:

---

Envoyé par Mohamed.Houri

à cause des objects cachés générés par Oracle lors de la création de ce type de table, et sans que vous ne soyez au courant, vous allez vous trouver avec de sérieux problèmes de performance et même de lock et de deadlocks;

---

Merci Mohamed. Indépendamment des performances et des contentions, il faut observer qu’Oracle viole le principe de l’information énoncé par Ted Codd, père du Modèle Relationnel de Données. Je vous renvoie au rappel fait par Chris Date dans ACM Sigmod à l’occasion de la disparition de Ted :

The entire information content of a relational database is represented in one and only one way: namely, as attribute values within tuples within relations.

Autrement dit, tout doit se passer en pleine lumière, rien ne doit être caché, sinon le développeur risque de faire des bêtises, quand bien même le marketing tiendrait des propos rassurants.

N.B. Au nom du principe d’interchangeabilité, il est évident que les vues sont concernées.

Citation:

---

Envoyé par CinePhil

Avec un modèle de données normalisé, ce serait quand même mieux ! :roll:

---

Je suppose que vous faites allusion à la 1NF (première forme normale). Mettre en œuvre un modèle normalisé au sens Merise (règle de vérification) comme vous l’avez fait est préférable, mais du point de vue de la théorie relationnelle, on ne viole pas la 1NF quand on niche des tables dans des colonnes (cf. le paragraphe 2.6 traitant des RVA (relation-valued attributes).

Cela dit, l’utilisation des RVA n’est pas satisfaisante, en effet on rend le système dissymétrique, en vertu de quoi le modèle que vous proposez est beaucoup plus raisonnable :

Code:

---

1 2 3 4 5 6

Tables : film (flm_id, flm_titre...) category (cat_id, cat_libelle) acteur (act_id, act_nom, act_prenom...) flm_avoir_cat (fac_id_film, fac_id_category) act_jouer_flm (ajf_id_acteur, ajf_id_film)

---

Par exemple, avec votre système, des inserts sont des inserts, sans surprise (respect de la symétrie). Avec des RVA (voyez la fin du paragraphe 2.6 cité), des inserts peuvent avoir à être transformés en updates par forcément simples (euphémisme). Manifestement l'excellent Waldar a souffert de la dissymétrie et autres conséquences cauchemardesques. Merci à lui pour son retour d’expérience !

Le problème de la performance des requêtes n’est pas à prendre en considération dans le cadre du débat en cours : au niveau théorique on est infiniment patient et les temps de réponse peuvent être infiniment longs. Néanmoins, par référence à ce que je lis ici, autant il doit être rapide de trouver les numéros de téléphone de M. Tartempion, autant on devra mesurer avec soin et rendre acceptables les temps de réponse des transactions quand il s’agit de retrouver la (ou les) personne(s) parmi dix millions ayant pour numéro le 0103426789. Si les DBA Oracle ont des tuyaux, ça serait sympa de leur part de nous en faire part, merci d'avance. ;)

Citation:

---

Envoyé par mnitu

J'ai finalement trouvé le paragraphe: Data Value Atomicity

---

Tout baigne. Le seul problème est que la page (34 en l’occurrence) est à moitié cachée (décidemment...) Incidemment, il est bon de comparer les relations R2 et R3 de la page suivante (Figure 2-1). Dans R2, on a plus d’une valeur à l’intersection d’une ligne et d’une colonne, ce qui traduit un viol de 1NF patent (et R2 n'est donc pas une relation), tandis qu’avec R3 on a exactement une valeur à l’intersection : la 1NF est en l’occurrence respectée.

En conclusion, comme le dit Date, le concept d’atomicité ne peut pas être défini de façon absolue. Personnellement j’en reste à ce que j’ai écrit au paragraphe 2.7 de mon article traitant de la normalisation.

En tout état de cause, ne serait-ce qu’au nom de la symétrie, il est clair que dans le contexte des bases de données en production, la modélisation pratiquée par CinePhil est à privilégier, et il faut fuir les Nested Tables d’Oracle puisque le principe fondamental de l’information est violé, sans parler des problèmes évoqués par Mohamed et Waldar.