reflexion construction de base de donnée pour annuaire hôtels et restaurantsRésolu

Question

J'ai besoin d'un coup de pouce !!!
Je m'explique,
j'ai une table "t_etablissement"
contenant plusieurs champs "id,nom,adresse,..."
et pour chaque établissement j'ai une série de 30 pictos à appliquer en tant que booléen.

exemple: 1 établissement aura 9 pictos(visa,mastercard,piscine,parking,...)
et un autre établissement aura 12 pictos.

Comment puis-je aplliquer cela dans ma DB ???

Merci d'avance pour votre aide.

neigedhiver · Accepted Answer

Salut,

Là, je suis pas entièrement d'accord...
Si je comprends bien, l'idée est de savoir si l'établissement a ou non le picto.
Si les pictos ne sont pas variables, on peut tout à fait les stocker simplement dans la table t_etablissement.
Après, la manière de stocker est à l'appréciation du développeur : un champ binaire avec toutes les valeurs, un champ par picto... Au choix.
Si les pictos pouvaient varier comme le peuvent des photos associées à un compte utilisateur, alors oui, une table séparée avec une table de jointure serait pertinent. Là, je n'en suis pas convaincu.

-- 
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

syndrael · Answer

Une table Picto qui recense tes pictos. Et une table Etablissement-Picto qui contient l'Id de l'établissement avec l'Id du picto..
S.

syndrael · Answer

Je pars toujours du principe suivant: Tout est variable !! LOL.. Surtout quand le besoin vient de quelqu'un qui ne connait pas la technique.
Simple question d'anticipation..
S.

neigedhiver · Answer

Quand je parle de variable, j'entends des données qui varient d'un enregistrement à l'autre. Là, ce n'est pas le cas : chaque établissement possède la donnée, pour chaque picto "présent ou pas". Sans exception. Ca, ce n'est pas ce que j'appelle du variable.
Par contre, si chaque établissement pouvait avoir N photos associés à sa fiche, alors oui, il faudrait une table séparée avec une table de jointure.
Mais dans l'élaboration du MCD, on aboutit au fait que dans le cas présent et lors de la conversion en MLD puis en MPD, on n'aboutit pas à une table séparée pour stocker cette information.
Si plus tard on rajoute un picto, on rajoute alors un champ, et on définit une valeur par défaut (0) pour ce picto, aux enregistrements déjà présents. Ce n'est pas "variable", mais jsute "évolutif".

Tu vois la différence que je fais ?

Cela dit, d'un point de vue purement fonctionnel, les deux solutions ... fonctionnent ;)

-- 
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

math567 · Answer

Merci pour vos réponses.
J'ai décidé d'ajouter 30 champs type booléen à ma table t_etablissement.
C'est ce que je pensais faire mais ça me semblait assez lourd.

syndrael · Answer

La première des choses qui varie c'est la demande et la personne qui exprime son besoin. LOL !!
Si tu es sur que tes 30 champs ne changeront pas y'a pas de souci. Perso je suis allergique aux tables de plus de 20 colonnes. 
Sinon tu fais comment si tu veux mettre un libellé pour tes pictos ? Ma solution permettait de lier tout cela.
S.

neigedhiver · Answer

Perso je suis allergique aux tables de plus de 20 colonnes. 

Ca, c'est complètement irrationnel ;)
Un SGBDR est tout à fait capable de gérer des tables avec de nombreuses colonnes et cela n'affecte en rien les performances. Pour ce qui est de la la "lisibilité", franchement, c'est un détail sans importance. 
Moi aussi, au début, je préférais avoir le moins de colonnes possibles... pis j'ai réalisé que ça n'avait pas de sens et qu'une table devait se composer des colonnes nécessaires et pis c'est tout lol

-- 
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

syndrael · Answer

Irrationnel ?? Pas de mot de plus de 5 lettres avec moi !! LOL !!
J'ai juste une préférence sur plusieurs tables qui me permettent d'avoir plus de souplesse sur les données. En effet, comment fait-on pour avoir la liste des 30 critères booléens de la question initialement posée ?? Il faut taper dans les tables 'systèmes' etc..
Et si on doit en rajouter un ? C'est parti pour les Alter Table avec peut-être un User SQL qui n'en a pas les droits (sécurité, sécurité & paranoia)..
Voilou pour mon point de vue avec une reponse de normand: Ca dépend.
Bonne soirée
S.

neigedhiver · Answer

Je peux toujours poser la question à mon frère qui est DBA Oracle sur des services de VOD de FAI. Mais je pense que je sais ce qu'il en pense...

En quoi est-ce un problème de faire un alter table ? Quand il y a migration de version, un alter table n'est qu'une ridicule requête SQL... Quand certains scripts font plusieurs centaines de Ko et prennent plusieurs pour effectuer une mise à jour, franchement, je ne vois pas où est le problème...

Non, mais t'as le droit de penser ce que tu veux, hein, sinon ;) Et de faire de même aussi ! Si ça marche et que t'es à l'aise avec, hein...

-- 
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

deupac · Answer

Hello,

Je me permets de répondre, même si une réponse semble avoir été déjà choisie... Je préviens avant de commencer que je ne bosse que sur Oracle et que donc, je ne m'engage pas sur les autres SGBDR quand je parle de performances.

D'un point de vue conception, je crois que vous êtes tous partis du mauvais pied si je puis me permettre... Pour répondre à la problématique de math567, il faut commencer par ne pas oublier que lorsque l'on met quelque chose dans une base de données, c'est toujours un élément du réel que l'on modélise. Une table (qui s'appelle une entité au niveau conceptuel) n'est autre que la représentation d'un objet du réel : une personne, un chèque ou dans le cas de math567, un établissement. Il faut ensuite se demander si un pictogramme fait partie intégrante d'un établissement et si il définit l'établissement en tant que tel. Le fait est que dans mon esprit, l'existence d'un ou plusieurs pictogrammes associés à un établissement ne peut en aucun cas définir le fait qu'un établissement en est vraiment un ou pas... En réfléchissant comme ça, on s'oriente naturellement vers la solution suivante : une entité établissement et une entité pictogramme. Vient ensuite la relation entre les deux. Un établissement peut avoir un ou plusieurs pictogrammes associés et un pictogramme peut-être associé à un ou plusieurs établissements. Cela se traduit donc par une relation dite [n;n] (c'est à dire 1,n des 2 côtés de l'association). 

Si on passe cela en physique (et là on peut parler de tables), on a donc 2 entités qui donnent 2 tables : établissement et pictogramme. La relation [n;n] donne toujours naissance à une table pour la matérialiser qui a pour primary key (PK) la concaténation des identifiants des tables reliées = une table etablissement_pictogramme (on prendra soin aussi de ne pas dépasser les 30 caractères si on bosse sur Oracle au passage, je connais pas les limitations des Postgresql et autres MySQL) avec pour PK (id_etablissement, id_pictogramme).

Voyons cependant l'autre solution qui était proposée : une colonne par pictogramme. Si on est sûr que les pictogrammes n'évolueront pas (surtout si l'on est sur qu'il n'y aura pas de rajout de pictogramme), ca peut passer, mais cela peut poser des problèmes si :

1 - on veut la liste de tous les pictogrammes existants : il faut effectivement récupérer le nom des colonnes et pas ce qu'elles contiennent ce qui n'a pas de sens d'un point de vue conception, puisqu'une colonne est faite pour stocker une valeur et pas pour ETRE la valeur (mis à part les booléens, mais on l'a vu plus haut, d'un point de vue conceptuel pur, le sens réel d'un pictogramme n'est pas booléen)

2 - on veut récupérer certaines informations sur les pictos associés aux établissements. Admettons que l'on veuille la liste de tous les établissements qui ont tel et tel picto mais pas tel et tel autre picto etc... On part pour des select de la mort avec jusqu'à potentiellement les 30 colonnes dans le where et là, on à intérêt à avoir indexé correctement ses 30 colonnes, ce qui soit dit en passant va peut-être être performant sur des select, mais je vous raconte pas la tronche des insert, des updates, des reconstructions d'index et des calculs de statistiques si la table est un peu grassouillette. C'est aussi pur cela que l'on utilise des tables d'associations sur lesquelles on ne cherche que des identifiants, donc des PK, donc des colonnes indexées.


D'une façon plus générale, on peut dire qu'une table qui possède trop de colonnes a de grandes chances d'avoir rencontré un souci avec son concepteur... Tout repose sur l'objet réel que l'on veut représenter. Mais il est évident qu'une table possédant 50 colonnes n'est sûrement pas bien conçue, sauf cas exceptionnels comme des tables d'historique ou de statistiques qui ne réprésentent pas vraiment d'objets réels et qui sont plus là dans des environnements datawarehouse.

Pour finir sur les avis de neigedhiver (salut frangin :) et de syndrael, un alter table est tout sauf un problème quand il est fait en migration, donc de façon prévue, scriptée et maîtrisée. Si le code commence à faire des alter table, là par contre, je m'inquiète.

Si chaque picto est une colonne de la table établissement, pour récupérer la liste des 30 pictos, il faut effectivement aller taper dans les tables système avec un truc du genre select column_name from user_tables where table_name='xxx';. C'est bien évidemment d'une lourdeur sans nom et cela sous-entend qu'on a correctement nommé ses colonnes (préfixées par picto_ par exemple) afin de pouvoir faire sa requête de façon optimale avec un LIKE, sinon bon courage. Mais d'un point de vue purement technique, pas de problème, les tables user_xxx ne sont pas des tables systèmes, mais des vues qui tapent sur des vues systèmes avec le nom du schéma dans le where. Je ne vois donc aucun inconvénient à ce qu'un script de migration ou même que le code aille taper là-dedans.

Voilà, voilà.... C'est tout ce que j'avais à dire, je m'excuse auprès de ceux que ma prose aurait ennuyé :)

Deupac.

deupac · Answer

Erf, je me corrige :

Pour récupérer les colonnes d'une tables, on interroge la vue user_tab_columns et pas user_tables, pardon...
J'ai aussi dis qu'une colonne n'est pas faite pour ETRE la valeur, sauf les booléens... Ce n'est pas tout à fait exact, une colonne prenant une valeur booléenne n'est pas non plus la valeur...


Deupac.

neigedhiver · Answer

Au temps pour moi.

-- 
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

neigedhiver · Answer

Ah si, j'ai quelque chose à rajouter pour ma défense !

Quand je voyais la nature des pictos (parking, etc) je me disais qu'effectivement, certains pouvaient définir un établissement (le fait qu'il ait ou non un parking, qu'il accepte ou non la CB, etc). C'est pour cela que je ne voyais pas d'inconvénient à ce que ces champs soient intégrés à la table établissement.

Cela dit, on peut voir ça de manière plus générale, et chaque "picto" (du coup, c'est la dénomination picto qui peut être trompeuse) peut être simplement considéré comme un "attribut", les attributs pouvant alors être variables d'un établissement à l'autre (il l'a : il est présent dans la table, il l'a pas, il n'y est pas...).

Je sais pas si c'est clair ce que je dis...

-- 
Neige

Souvent la réponse à votre question se trouve dans la doc. Commencez par là ;)

kohntark · Answer

Salut,

je m'excuse auprès de ceux que ma prose aurait ennuyé :) 
Je trouve cela totalement inadmissible de se permettre de pareils post, c'est honteux !! 

Je ne suis pas expert, mais j'aurai tendance à suivre Syndrael lorsqu'il dit : "ça dépend" ... et Neige lorsqu'il parle "d'attribut".
Ta réflexion est intéressante Deupac mais elle n'intègre pas suffisamment le but final.
Tout le problème est là à mon avis.
Pour reprendre un de tes exemples, une "personne" pourra être "définie" par sa profession, son âge, son nombre d'enfants, son statut marital, ... ou par son style musical, son instrument, ses années de pratique, ses influences artistiques, ses formations, ...
Dans les deux cas toutes les données auront leur utilité, mais la construction de la DB dépendra de ce "but final".
Un site de rencontres privilégiera des tables séparées pour le premier cas, un site de zicos le fera pour le second.
En d'autres termes cela dépend du contexte et donc des requêtes / manipulations qu'il y aura à faire sur la DB.

Pour ce qui est du problème initialement posé, et en considérant le titre du thread et donc le but final, je ferai une table séparée pour les pictos (même si je pense que ces "pictos" définissent, dans ce cas, l'établissement), afin de faciliter les requêtes du style "je cherche un établissement acceptant la carte bleue n'ayant pas de piscine ni de parking, ni de TV ni de douche et WC individuels ... mais acceptant 3 gros chiens" (si cette requête donne qqchose je suis preneur )

Je n'ai pas bien compris pour quelle raison il faudrait "taper" dans les tables système ou les vues pour connaitre le nom des colonnes (??)


Cordialement,



Kohntark -

deupac · Answer

Hello,

Ma réflexion intègre parfaitement le but final, c'est pour cela que je rappelle qu'il faut toujours garder à l'esprit que tout ce qui se modélise existe dans la vraie vie (et vice versa). Par contre, la construction d'une base de données se fait en plusieurs temps : 

1. analyse et conception du modèle en respectant les règles de modélisation de la méthode que l'on utilise (MERISE ici on est tous d'accord)

2. transformation du modèle conceptuel en modèle logique pour essayer tant que possible de partir sur de bonnes bases avec les formes normales et tout le bazar

3. modélisation physique : on transforme les entités en tables, les associations en relations, les identifiants en clés primaires, les cardinalités en clés étrangères etc etc... Et c'est seulement à cette étape que l'on prend en compte certaines contraintes liées purement au développement et à l'ergonomie de la chose. Si on commence à dénormaliser avant, il y a un problème

Dans le cas présent, c'est une fois arrivé à la dernière étape que l'on se rend compte que la seule solution viable, que l'on ait pris ou pas en compte le but final dès le départ, c'est de faire 2 tables :)

Là où tu as raison, c'est que je n'ai certainement pas assez détaillé ma pensée.

Quoi qu'il en soit, on est parfaitement d'accord et tu as bien complété mon post, je t'en remercie. 

Pour ce qui est de cette histoire de vues système, pour connaître le nom des colonnes d'une table, 2 possibilités : les avoir en dur dans un fichier quelque part, ou alors interroger la vue user_tab_columns sur Oracle, accessible à tout utilisateur et qui donne des informations uniquement sur les tables dont l'utilisateur en question est propriétaire. Il y a encore d'autres vues, selon que l'on est utilisateur, sys ou system, comme dba_tab_columns, dba_tab_cols, all_tab_columns, all_tab_cols, qui présentent toutes des petites différences, mais je ne les connais pas toutes.


Deupac.

syndrael · Answer

Allez hop un post en plus..
Pour une fis, j'apprécie qu'on présente nos différentes visions d'une base de données. Est-ce qu'on s'adapte au besoin ? est-ce qu'on utilise toujours le même type de raisonnement etc..
Ca change de: 'Ca veut dire quoi Warning at line 10 !!'
Pour répondre à Kohntark: 
Je cherche un établissement acceptant la carte bleue n'ayant pas de piscine ni de parking, ni de TV ni de douche et WC individuels ... mais acceptant 3 gros chiens" --> rappelle moi de ne pas t'inviter chez moi !! LOL !!

Je n'ai pas bien compris pour quelle raison il faudrait "taper" dans les tables système ou les vues pour connaitre le nom des colonnes (??) C'est dans le cas ou tu voudrais 'lier' une des 30 colonnes 'binaires' de picto à un libellé par exemple. Je me vois mal appeler une colonne 'Possède un parking'
Voilou.. allez je repars à mon dur labeur, il faut bien nourrir mon gosse !! LOL !!
S.

deupac · Answer

Ah oui tiens, j'avais mal compris le sens de la phrase "Je n'ai pas bien compris pour quelle raison il faudrait "taper" dans les tables système ou les vues pour connaitre le nom des colonnes (??)"... Désolé, merci Syndrael pour avoir rattraper mon incompréhension :) 

Deupac.

Reflexion construction de base de donnée pour annuaire hôtels et restaurants

17 réponses

Votre réponse

Discussions similaires