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 ?
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....
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 ?
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....
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....
Patrick Texier
Le Fri, 26 Oct 2007 07:26:57 +0200, ALain Montfranc a écrit :
> 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
Le Fri, 26 Oct 2007 07:26:57 +0200, ALain Montfranc a écrit :
> 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
Le Fri, 26 Oct 2007 07:26:57 +0200, ALain Montfranc a écrit :
> 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
yves a écrit :
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/
yves a écrit :
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/
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
P'tit Marcel writes:
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.
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
yves
Le Fri, 26 Oct 2007 13:16:19 +0200, P'tit Marcel a écrit:
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
Le Fri, 26 Oct 2007 13:16:19 +0200, P'tit Marcel a écrit:
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?
Le Fri, 26 Oct 2007 13:16:19 +0200, P'tit Marcel a écrit:
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
yves
Le Sat, 27 Oct 2007 22:36:58 +0200, P'tit Marcel a écrit:
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
Le Sat, 27 Oct 2007 22:36:58 +0200, P'tit Marcel a écrit:
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.
Le Sat, 27 Oct 2007 22:36:58 +0200, P'tit Marcel a écrit:
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
Le Sat, 27 Oct 2007 22:30:23 +0200, |-| /- |_ ()7 [°¿°] a écrit:
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
Le Sat, 27 Oct 2007 22:30:23 +0200, |-| /-\ |_ ()7 [°¿°] a écrit:
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à.
Le Sat, 27 Oct 2007 22:30:23 +0200, |-| /- |_ ()7 [°¿°] a écrit:
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
yves
Le Sun, 28 Oct 2007 15:17:08 +0100, P'tit Marcel a écrit:
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
Le Sun, 28 Oct 2007 15:17:08 +0100, P'tit Marcel a écrit:
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.
Le Sun, 28 Oct 2007 15:17:08 +0100, P'tit Marcel a écrit:
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
P'tit Marcel writes:
Christophe Cuq a écrit :
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 :-)
Toutafé, mais pour dénormaliser un modèle relationnel, il faut avoir su le normaliser en premier lieu :-)
Certes :)
-- CHC
Fred Brouard - SQLpro
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 +
-- 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 *************************
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 +
--
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 *************************
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 +
-- 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 *************************
