tables, etc
yves
Question (de béotien):
Arrive-'il (souvent ?, quelquefois ?, jamais ?) d'avoir dans une base de
données les champs nom, prénom et date de naissance dispersés dans
différentes tables ?
--
yves
ALain Montfranc
Dans une base généalogique, ca pourrait être logique de séparer le nom
du prenom (quoique, l'orthographe fixe des noms de famille étant assez
récente...). Sinon....
Patrick Texier
> > Arrive-'il (souvent ?, quelquefois ?, jamais ?) d'avoir dans une base de
> > données les champs nom, prénom et date de naissance dispersés dans
> > différentes tables ?
> Dans une base généalogique, ca pourrait être logique de séparer le nom
> du prenom (quoique, l'orthographe fixe des noms de famille étant assez
> récente...). Sinon....
Même pas. Une personne est identifiée par une clé et une clé secondaire
nom+prénom. Si on veut trier correctement cette clé secondaire, il faut
sortir la particule du champ nom.
Pour les variations de noms, on peut envisager une table de regroupement
des noms : la phonétique (soundex même adapté) ne suffit pas.
La naissance est par contre généralement enregistrée dans une table
séparée d'événements individuels. Au XVIIIe siècle et avant, les dates
de naissance ne sont souvent plus indiquées sur les actes de baptème.
C'est un autre événement.
Il y a un modèle de données à la fin de la description du standard
d'échanges Gedcom (en anglais) :
<http://www.familysearch.org/GEDCOM/GEDCOM55.EXE> Fichier Windows.
--
Patrick Texier
bases de données MySQL 4.1 libres :
<http://www.gpsql.org> sport automobile en circuit
<http://www.genindre.org/perso/foot.htm> football
P'tit Marcel
> Arrive-'il (souvent ?, quelquefois ?, jamais ?) d'avoir dans une base de
> données les champs nom, prénom et date de naissance dispersés dans
> différentes tables ?
Mis à part le cas particulier de la généalogie (voir les autres
réponses), c'est en pratique assez rare. Généralement, on place dans la
même table les attributs invariants d'une entité (ici, une personne).
Tous les attributs indépendants et monovalués d'une entité sont
habituellement regroupés dans la même table (nommée d'après cette entité).
L'inverse n'est pas forcément une erreur mais peut dénoter une
modélisation des données qui n'est pas normalisée.
--
P'tit Marcel
stats sur les forums modérés http://www.centrale-lyon.org/ng/
Christophe Cuq
> L'inverse n'est pas forcément une erreur mais peut dénoter une
> modélisation des données qui n'est pas normalisée.
La dénormalisation peut aussi être volontaire.
--
CHC
P'tit Marcel
> La dénormalisation peut aussi être volontaire.
Toutafé, mais pour dénormaliser un modèle relationnel, il faut avoir su
le normaliser en premier lieu :-)
a+
--
P'tit Marcel
yves
Bonjour,
> Mis à part le cas particulier de la généalogie (voir les autres
> réponses), c'est en pratique assez rare. Généralement, on place dans la
> même table les attributs invariants d'une entité (ici, une personne).
> Tous les attributs indépendants et monovalués d'une entité sont
> habituellement regroupés dans la même table (nommée d'après cette
> entité).
> L'inverse n'est pas forcément une erreur mais peut dénoter une
> modélisation des données qui n'est pas normalisée.
Merci.
J'ai demandé à l'informaticien de mon établissement (un petit hôpital) de
sortir une liste "numéro permanent, nom, prénom, date de naissance" à
partir du programme de gestion administrative, fondé sur Oracle. Ca semble
lui poser un problème technique. Il dit que la base de données possède
plusieurs centaines de tables, que les noms des tables ne sont pas
explicites, et qu'il a oublié la structure des tables de cette base.
Je lui ai dit que ces infos étaient probablement dans une même table, et
qu'il devait bien exister des techniques pour retrouver dans laquelle,
mais il a soutenu que les infos étaient probablement dispersées dans des
tables différentes.
Les choses en sont là, on attend la réponse par courriel des développeurs
de l'application, réponse qui n'arrive pas pour l'instant.
Existe t-il, à votre connaissance, une technique, pour repérer, dans une
grosse base de données Oracle, la table qui comprend les données
sus-citées, sans ouvrir les tables une par une?
--
yves
|-| /-\\ |_ ()7 [°¿°]
Dans le cas particulier du secteur de la santé, il arrive que les informations nominatives soient
séparées (isolées des autres données), pour des obligations légales (plus exactement ministérielles)
d'anonymisation.
Le même genre de démarche est souvent de mise, chaque fois qu'il s'agit de données sensibles.
Pour le cas d'Oracle, il y a la possibilité de voir le schéma de la base (structure des tables /
noms des champs) dans des tables spéciales, comme DBA_TAB_COLUMNS ALL_TAB_COLUMNS
USER_TAB_COLUMNS.
Enfin, que qu'un informaticien dise qu'il a "oublié" la structure des tables signifie, soit qu'il
cherche à se faire vire, soit qu'il s'estime inexpugnable...
@-salutations
Michel Claveau
P'tit Marcel
> J'ai demandé à l'informaticien de mon établissement (un petit hôpital) de
> sortir une liste "numéro permanent, nom, prénom, date de naissance" à
> partir du programme de gestion administrative, fondé sur Oracle. Ca semble
> lui poser un problème technique. Il dit que la base de données possède
> plusieurs centaines de tables, que les noms des tables ne sont pas
> explicites, et qu'il a oublié la structure des tables de cette base.
Problème classique dans les hopitaux : ancienneté des applications,
dépendance complète envers les éditeurs (GIP/GIE ou privés), priorité du
hardware sur le software, etc.
> Existe t-il, à votre connaissance, une technique, pour repérer, dans une
> grosse base de données Oracle, la table qui comprend les données
> sus-citées, sans ouvrir les tables une par une?
oui, il suffit de sélectionner à partir de la structure de la base. Sauf
erreur, cela se fait sous Oracle avec des SELECT sur les tables
DICTIONARY et/ou USER_TABLES et/ou USER_TAB_COLUMS et/ou USER_CONSTRAINTS.
Cela dit, le plus simple consiste à faire travailler Microsoft Access :
- faire installer sur un PC le driver ODBC pour Oracle
- faire créer un lien ODBC sur la base Oracle quivabien
- créer un base Access vide
- aller sélectionner les tables Oracle par le menu
Données Externes/Lier/ODBC (shift clic est une amie)
- Outils/Analyse/Documentation/Tables
- aller se coucher pendant que cela mouline
- le lendemain, si tout va bien, Access a créé un document énorme à
exporter incontinent au format RTF
Il vaut mieux utiliser un PC costaud...
Le document RTF rassemble plein d'info pertinentes pour aller à la pêche
aux données (nom des tables, nombre de lignes des tables, nom des
colonnes, format et taille des colonnes).
Pour la question posée, il vaut mieux cibler :
- les tables avec des milliers de lignes (à moins que ce soit vraiment
un tout petit hôpital :-),
- les colonnes au format date,
- les colonnes texte assez longues (> 20 car),
- les colonnes texte de 13 car,
- etc.
NB: attention à la réglementation sur les traitements de données
personnelles (confère loi de 1978)
eça
nobody
>> J'ai demandé à l'informaticien de mon établissement (un petit hôpital) de
>> sortir une liste "numéro permanent, nom, prénom, date de naissance" à
>> partir du programme de gestion administrative, fondé sur Oracle. Ca
>> semble
>> lui poser un problème technique. Il dit que la base de données possède
>> plusieurs centaines de tables, que les noms des tables ne sont pas
>> explicites, et qu'il a oublié la structure des tables de cette base.
>
> Problème classique dans les hopitaux : ancienneté des applications,
> dépendance complète envers les éditeurs (GIP/GIE ou privés), priorité du
> hardware sur le software, etc.
>
>
le probleme technique est que justement ce n'est pas oracle mais un
system PICK et que le mec ne sait pas lire une table pick
je présume que "l'informaticien" est un universitaire et donc ne connait
pas les systemes PICK qui sont (etait) dans tout les hopitaux
dit lui de commencer par faire : LISTER-FICHIER
yves
Bonjour,
> Problème classique dans les hopitaux : ancienneté des applications,
> dépendance complète envers les éditeurs (GIP/GIE ou privés), priorité du
> hardware sur le software, etc.
Oui, tout à fait.
Le plus inquiétant, c'est l'incapacité totale pour les intervenants, et en
particulier ceux qui tiennent les carnets de chèque, de percevoir mieux
les racines techniques de cette dépendance. Pour moi, à long terme, il n'y
a qu'un seul moyen de sortir de l'ornière (mais pas au niveau de notre
seul petit établissement, hélas), moyen qui s'appelle: "logiciel libre".
Qu'en j'en cause, j'ai l'impression de causer extra-terrestre.
Mais, bon, assez, je ne veux pas lancer de troll.
> Le document RTF rassemble plein d'info pertinentes pour aller à la pêche
> aux données (nom des tables, nombre de lignes des tables, nom des
> colonnes, format et taille des colonnes).
Merci.
> NB: attention à la réglementation sur les traitements de données
> personnelles (confère loi de 1978)
Oui.
Mon problème est le suivant:
Je suis le responsable du laboratoire d'analyses.
Je dispose de ma propre "base de données", qui s'est développée au fil du
temps indépendamment du logiciel de gestion administrative de l'hôpital
(C-page). Evidemment, les deux logiciels proviennent de fournisseurs
différents.
Les patients enregistrés dans ces deux bases sont les mêmes.
La direction de l'hôpital veut que j'adopte, dans mon logiciel de labo,
les numéros permanents de C-Page (le but est de renvoyer à terme les
résultats d'analyses dans un autre logiciel, d'un troisième fournisseur !!!)
Il y a depuis peu une "passerelle" pour ça.
Malheureusement, un jour, dans mon logiciel, deux dossiers de patients
différents ont fusionnés (je suppose que le np du patient X dans C-page
correspondait à celui d'un patient Y dans mon logicielLabo, notre
secrétaire a du valider la mauvaise option, sans même dire "Oups...". ).
J'ai une liste np, nom, prenom, date de naissance en provenance de mon
logiciel de labo (9000 personnes, environ)
Je voudrais la même en provenance de C-page.
Et attaquer les deux listes à coup de scripts python et/ou de sql pour
identifier "préventivement" les patients différents qui auraient un np
identiques dans les deux bases.
Ca permettra au moins d'évaluer la taille de l'épée de Damoclès qui pèse
sur l'intégrité de ma base.
--
yves
yves
Bonjour,
> Dans le cas particulier du secteur de la santé, il arrive que les
> informations nominatives soient séparées (isolées des autres données),
> pour des obligations légales (plus exactement ministérielles)
> d'anonymisation.
> Le même genre de démarche est souvent de mise, chaque fois qu'il s'agit
> de données sensibles.
>
> Pour le cas d'Oracle, il y a la possibilité de voir le schéma de la base
> (structure des tables / noms des champs) dans des tables spéciales,
> comme DBA_TAB_COLUMNS ALL_TAB_COLUMNS USER_TAB_COLUMNS.
Ok, merci.
> Enfin, que qu'un informaticien dise qu'il a "oublié" la structure des
> tables signifie, soit qu'il cherche à se faire vire, soit qu'il s'estime
> inexpugnable...
Il a suivi un stage d'administration de cette application, mais il a
plusieurs années de celà.
--
yves
P'tit Marcel
> Je dispose de ma propre "base de données", qui s'est développée au fil du
> temps indépendamment du logiciel de gestion administrative de l'hôpital
> (C-page). Evidemment, les deux logiciels proviennent de fournisseurs
> différents.
> J'ai une liste np, nom, prenom, date de naissance en provenance de mon
> logiciel de labo (9000 personnes, environ)
>
> Je voudrais la même en provenance de C-page.
Je ne serai pas surpris que CPage fonctionne avec une base Oracle. Par
ailleurs, l'éditeur existe toujours et il doit proposer une hot line par
téléphone ou mail. On doit pouvoir le retrouver sans avoir à sortir la
grande lunette du mont pAlomar...
L'autre piste est de voir du côté du DIM (sauvegarde des fichiers VID-HOSP).
> Et attaquer les deux listes à coup de scripts python et/ou de sql pour
> identifier "préventivement" les patients différents qui auraient un np
> identiques dans les deux bases.
Je n'ai rien contre les logiciels GNU. Cependant, dans le cas précis, le
plus simple est d'utiliser Access avec un lien ODBC vers la base CPage
et un autre vers la base (ou la liste extraite) Biologie, puis enfin de
créer une petite requête en jointure sur les tables.
Attention aux nouveaux nés qui partagent parfois l'identifiant de la
mère, et aux approximations dans la saisie des noms/prénoms
Etienne Valquez
> plus simple est d'utiliser Access avec un lien ODBC vers la base CPage
> et un autre vers la base (ou la liste extraite) Biologie, puis enfin de
> créer une petite requête en jointure sur les tables.
ben non. C'est le boulot d'un ETL et Talend fait ça à la perfection car
il est conçu pour ce job. On imagine bien Access avec les différents
charset sans parler du volume de données !
yves
> Je ne serai pas surpris que CPage fonctionne avec une base Oracle.
Oui, c'est sûr. CPage fonctionne avec une base Oracle.
> Par ailleurs, l'éditeur existe toujours et il doit proposer une hot line
> par téléphone ou mail. On doit pouvoir le retrouver sans avoir à sortir
> la grande lunette du mont yAlomar...
Oui, notre informaticien leur a droppé un e-mail, m'a-t-il dit, mais on
attend toujours une réponse.
> L'autre piste est de voir du côté du DIM (sauvegarde des fichiers
> VID-HOSP).
Notre hôpital est vraiment petit, je connais bien l'unique membre du DIM,
c'est un ami, et ce n'est pas la peine de lui demander quoi que ce soit
d'informatique :-)
> Je n'ai rien contre les logiciels GNU. Cependant, dans le cas précis, le
> plus simple est d'utiliser Access avec un lien ODBC vers la base CPage
> et un autre vers la base (ou la liste extraite) Biologie, puis enfin de
> créer une petite requête en jointure sur les tables.
>
> Attention aux nouveaux nés qui partagent parfois l'identifiant de la
> mère, et aux approximations dans la saisie des noms/prénoms
L'avantage majeur de Python (http://www.python.org/) (et de sqlite
(http://www.sqlite.org/) que je pense utiliser en conjonction
(http://docs.python.org/lib/module-sqlite3.html)), c'est que je les
connais suffisamment bien, pour faire assez facilement ce job!
Voici un extrait de fichier .csv en provenance de mon logiciel de labo:
"542312","DURAND","GEORGETTE","DUPOND","18031945"
"3389","LEFEVRE","BERNARD","","24021990"
Python est tellement flexible que, quel que soit le format du fichier .csv
issu de CPage, il sera facile de le lui faire transformer pour se
conformer au format ci-dessus.
--
yves
Christophe Cuq
Fred Brouard - SQLpro
oui cela depend de beaucoup de choses. Ainsi dans une base rencensant
100 millions d'individu, vu la faible dispersion des prénoms en regards
des noms il a été jugé utile de mettre les prénoms dans une table en
relation 1:n cela a permis de diminuer de manière très sensible le
volume des données de la table des personnes et par là même d'augmenter
les performnces à tous niveaux...
En revanche pour le couple de données nom/date naissance c'est moins
évident, une date de naissance pouvant être représentée avec au plus 21
bits (soit ua plus 3 octets) du 1/1/1 au 31/12/4095 et en fait 2 octets
pour les dates depuis la réfome du calendrier grégorien jusqu'à nos
jours prochains...
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
*********************** http://www.sqlspot.com *************************
nobody
> yves a écrit :
>> Bonjour,
>>
>> Question (de béotien):
>>
>> Arrive-'il (souvent ?, quelquefois ?, jamais ?) d'avoir dans une base de
>> données les champs nom, prénom et date de naissance dispersés dans
>> différentes tables ?
>>
>
> oui cela depend de beaucoup de choses. Ainsi dans une base rencensant
> 100 millions d'individu, vu la faible dispersion des prénoms en regards
> des noms il a été jugé utile de mettre les prénoms dans une table en
> relation 1:n cela a permis de diminuer de manière très sensible le
> volume des données de la table des personnes et par là même d'augmenter
> les performnces à tous niveaux...
>
> En revanche pour le couple de données nom/date naissance c'est moins
> évident, une date de naissance pouvant être représentée avec au plus 21
> bits (soit ua plus 3 octets) du 1/1/1 au 31/12/4095 et en fait 2 octets
> pour les dates depuis la réfome du calendrier grégorien jusqu'à nos
> jours prochains...
>
> A +
>
2octets = 65536 valeurs soit 179 ans 157 jours
la réfome du calendrier grégorien est le 15 octobre 1582
http://fr.wikipedia.org/wiki/Calendrier_gr%C3%A9gorien
donc Fred Brouard est en 1762 ce qui explique sans doute sont retard en
technologie de SGBD puisque il est entre Blaise Pascal et Augusta Ada
King soit a la programmation des metiers à tisser de Joseph Marie
Jacquard sur carte perforées :-)
Fred Brouard - SQLpro
Ah parce que vous en êtes déjà aux cartes perforées Jacquard chez vous ???
;-)
nobody
encore en 1762 perfore et tais toi :-)
et 21 bits ne donne pas du 1/1/1 au 31/12/4095 mais du 01/01/01 au
03/11/5741
bref Fred Brouard confirme de manière irréfutable l'opinion qu'on de lui
les personnes qui le connaissent personnellement et à qui j'ai demander
leur opinion sur lui au linux-expo 2007 et au RMLL2007
suite à cette démonstration de compétence du Sir Fred Brouard nous
pouvons évalué à leur juste valeur 'l'oeuvre littéraire de fiction sur
les SGBD" de sus nommé sans même avoir à se farcir leur lecture
en effet un "expert bases de données et langage SQL" qui ne sait même
pas évalué correctement la codification de date dans un SGBD ne peut
être que de compétences limité dans ce domaine.
nobody
http://brouardf.club.fr/TVplateau.gif
et voici le portrait de Fred l'expert extrait de la page
"http://brouardf.club.fr/MotoPerroquetPortrait.html" :
:
"Lui c'est LE pur ... Son truc c'est "no future", punk's not dead ... il
va aux concerts rocks tous les w.e., il allume tous ceux qui portent pas
un blouson noir et qui ont les ongles propres... il les défit en ouvrant
les canettes de Kronenbourg avec ses dents! Il coupe ses marlboro avec
de l'huile de ricin solidifiée et il éructe bruyamment quand il voit un
documentaire de l'ORTF sur les premiers pas de Léon Zitrone sur le petit
écran.
Quant son R1 chauffe trop, il pisse dessus... S'il y a un concours du
plus gros mangeurs de rillettes, il s'inscrit mais en plus il bouffe des
oeufs durs et des knaki herta (ne passons pas à côté des choses simples)
pour
avoir plus de mérite encore. Quand il va à la FNAC acheter un disque il
pète un bon coup pour faire fuir la foule qui l'incommode et comme ça il
peut acheter des compil au rabais (néo-punk pour 30 balles, à ce prix là
ça vaut
pas le coup de les chourrer). Il s'injecte des laxatifs dans les veines
pour éliminer deux fois plus vite (et donc gagner du temps) sans même
prendre la peine de se payer sa pause kit kat aux chiottes avec un
canard de moto pour se dillater le sphincter en toute sérennité. Lâché
dans le désert du nevada il choppe les coyotes et s'en fait une moumoute
pour faire croire à ses ennemis qu'il craint même pas la chaleur, il a
même presque froid. Il a
l'oeil vitreux mais aux aguets et son haleine aux relents de tequila à
bon prix vient à bout des mouches vertes les plus résistantes. Chez lui
il fait la collection des tracts anarchistes polonais de la fin du XIX °
siècle et il chope une érection en lisant l'assassinat de Henri IV par
son modèle Ravaillac.
Il ne s'exprime pas, il hurle, parce qu'il se souvient d'une vie
antèrieure où il n'était qu'un caillou perdu sur le Larzac au temps où
les dinosaures faisaient des partouzes en pleine garrigue et que pour se
faire entendre, il
fallait oser gueuler plus fort encore.
Et surtout il a les dix commandements de la sacro sainte FFMC pendus
dans tous les murs de sa piaule, il récite des bréviaires en japonais
puis va se tailler le jonc en matant les posters envoyés par son cousin
qui bosse chez
Yamaha Japon.
Lui, c'est LE pur, le hayatollah imberbe des motards, le grand
inquisiteur de la FFMC.
Alors les autres... c'est no future! : o)))"
Etienne Valquez
>
> Alors les autres... c'est no future! : o)))"
>
bon, docteur bonux, tu nous les brises menu
nobody
> nobody a écrit :
>>
>> Alors les autres... c'est no future! : o)))"
>>
>
> bon, docteur bonux, tu nous les brises menu
et si le portrait de l'expert fait par un de ses proches te dérange
plaint toi au rédacteur pas à moi il y a d'ailleurs un lien vers le
rédacteur sur la page http://brouardf.club.fr/MotoPerroquetPortrait.html
et à propos de "Docteur" je supposes que vous parler de "Helios"
je l'ai croisé le 25 chez IBM ou il passait (sortie de sa retraite) dans
une réunion sur les SGBDR et il m'a semblait plûtot très apprécié
(presque tout les présents lui on demander des cartes de visite et donné
la leur)
Etienne Valquez
> et à propos de "Docteur" je supposes que vous parler de "Helios"
> je l'ai croisé le 25 chez IBM ou il passait (sortie de sa retraite) dans
> une réunion sur les SGBDR et il m'a semblait plûtot très apprécié
mais oui, docteur bonux, il n'y a pas de mal à s'astiquer.
PS: demande à Free de te changer ton @ IP
nobody
l'IP de Helios est 81.56.138.142 et il me semble que mon ip est
88.175.144.136
Thierry B.
> et à propos de "Docteur" je supposes que vous parler de "Helios"
> je l'ai croisé le 25 chez IBM ou il passait (sortie de sa retraite) dans
> une réunion sur les SGBDR et il m'a semblait plûtot très apprécié
>
> (presque tout les présents lui on demander des cartes de visite et donné
> la leur)
C'est sûr qu'une carte de visite avec des gifs animées dessus,
c'est quand même assez collector. Ceci dit, comme vous semblez
parti vers un troll largement glauque, je vous propose de laisser
les gens bosser tranquille, et d'aller discuter ailleurs de la
punkitude qui semble vous fasciner...
--
> Au fait, vous savez que votre cagoule est percée ?
Savez vous qu'une cagoule non perçée n'est utilisable que par un aveugle ?
--{ JGDL, dans fr.misc.divers }--
ALain Montfranc
> voici la tronche de l'expert (le mec en blouson)
Tu sais, quand on voit ta gueule à toi....
nobody
> nobody a écrit
>
>> voici la tronche de l'expert (le mec en blouson)
>
> Tu sais, quand on voit ta gueule à toi....
>
>
tu as une photo de moi tu es très fort car aucune photo de moi n'est sur
le net à ma connaissance .
envois donc cette photo sur mon email mohamed...@tiscali.fr que je
puisse la voir .
ALain Montfranc
> ALain Montfranc a écrit :
>> nobody a écrit
>>
>>> voici la tronche de l'expert (le mec en blouson)
>>
>> Tu sais, quand on voit ta gueule à toi....
>>
>>
>
> tu as une photo de moi tu es très fort car aucune photo de moi n'est sur le
> net à ma connaissance .
prouve le (tm)
lol
Ph. B.
'tain, z'ont réussi à le cloner !
déjà qu'un seul, ce n'était pas une sinécure... :-D
Etienne Valquez
>
> 'tain, z'ont réussi à le cloner !
>
> déjà qu'un seul, ce n'était pas une sinécure... :-D
Soyons rassurés: cette orthographe et ce massacre de la langue française
est une vraie signature :-)
ALain Montfranc
> <troll>
Relire