FR 2909203 A1 20080530 FR 0610257 A 20061123 1 PROCEDE ET DISPOSITIF POUR LA SYNCHRONISATION DE BASES DE DONNEES HETEROGENES La présente invention concerne une solution pour consulter, éditer, mettre à jour et synchroniser un ensemble de bases de données hétérogènes et propose un procédé et un système pour la synchronisation de bases de données dont certaines informations d'une ou plusieurs desdites bases de données sont dépendantes de certaines autres informations d'une ou plusieurs autres desdites bases de données. Le problème général est de fournir un dispositif capable de synchroniser et de mettre à jour un ensemble de bases de données hétérogènes et indépendantes. Un exemple de bases de données hétérogènes et non synchronisées automatiquement à ce jour est trouvé dans les clubs de sport ou il est nécessaire de gérer d'un côté des bases de données de membres du club de sport et de l'autre un ensemble de bases de données sur la réservation et l'occupation des Lieux comme des salles et terrains de sport, des courts de tennis, des départs sur un parcours de golf ou encore des matériels de musculation. Par ailleurs, les membres d'un club ne se connaissant que très peu entre eux, une demande des membres est d'avoir la possibilité de rencontres- et de jouer avec de nouveaux partenaires. La réservation optionnelle d'un Lieu et la Recherche de Partenaires est un service qui doit être rendu par le procédé de synchronisation de bases de données hétérogènes. Par le document EP16844194 (SAP AG), on connaît un service de synchronisation central pour applications de type base de données. Toutefois, la méthode décrite ne 2909203 2 permet pas de s'adapter à des applications comme la réservation de terrains de sport afin de bloquer temporairement ou définitivement un Lieu pour un utilisateur donné. 5 Par ailleurs, le document WO2005055083 (Thomson Licensing SA) décrit un dispositif et un procédé d'extraction d'informations d'une base de données. Ce procédé ne permet pas de prendre en compte des paramètres de déterminations successives comme par exemple 10 l'utilisation d'un badge ou d'une carte à puces pour autoriser l'accès au Lieu qui a été réservé. Afin de corriger ces différents défauts, l'invention concerne selon son acception la plus générale, un procédé pour synchroniser un ensemble de 15 bases de données hétérogènes et propose un procédé et un système pour la synchronisation de bases de données dont certaines informations d'une ou plusieurs bases de données sont dépendantes de certaines autres informations d'une ou plusieurs autres bases de données. 20 L'invention concerne un procédé pour la synchronisation de bases de données hétérogènes comprenant au moins une base de données des Utilisateurs, au moins une base de données des Registres des Utilisateurs, au moins une base de données des Critères 25 des Lieux, et au moins une base de données des Occupations des Lieux, caractérisé en ce que l'on procède, avant la modification de certaines données de ladite base de données des Occupations des Lieux et la modification de certaines données de ladite base de 30 données des Registres des Utilisateurs, à la vérification de la compatibilité de certaines informations de ladite base de données des Critères des Lieux et de ladite base de données des Utilisateurs. 2909203 3 Avantageusement, ladite base de données des Utilisateurs est complétée par une base de do:znées des Préférences desdits Utilisateurs. Dans un mode de réalisation particulier, certaines 5 données de ladite base de données des Occupations des Lieux sont modifiées par blocs de données. Avantageusement, certaines données de ladite base de données des Occupations des Lieux sont modifiées par un Utilisateur, en fonction des paramètres de ladite base 10 de données des Utilisateurs. Avantageusement, certaines données de ladite base de données des Occupations des Lieux sont modifiées par un Utilisateur, en fonction des paramètres de ladite base de données des Critères des Lieux. 15 Dans un autre mode de réalisation, ladite base de données des Occupations des Lieux est synchronisée avec ladite base de données des Registres des Utilisateurs. Avantageusement, un utilisateur de ladite base de données des Utilisateurs prend une option Réservée pour 20 Recherche de partenaires dans ladite base de données des Occupations des Lieux. Avantageusement, un mèl (email) est envoyé sur les terminaux des partenaires potentiels suite à ladite prise d'option Réservée pour Recherche de partenaires dans 25 ladite base de données des Occupations des Lieux. Avantageusement, un SMS est envoyé sur les terminaux des partenaires potentiels suite à ladite prise d'option Réservée pour Recherche de partenaires dans ladite base de données des Occupations des Lieux. 30 De plus, l'invention concerne un système de synchronisation de bases de données hétérogènes comportant un serveur pour la mise en oeuvre du procédé et au moins un réseau local sur lequel est connecté au moins 2909203 un lecteur de badges. Avantageusement, le système comporte en outre au moins un terminal de saisie et de consultation connecté audit réseau local. 5 Avantageusement, l'accès à un Lieu est conditionné à la lecture d'un badge Utilisateur, aux informations de ladite base de données des Occupations des Lieux et aux informations de ladite base de données des Critères des Lieux. 10 La présente invention sera mieux comprise à la lecture de la description d'un exemple non limitatif de réalisation qui suit, ce référant au dessin annexé qui décrit l'architecture d'ensemble d'un système pour la mise en oeuvre du procédé selon l'invention 15 Dans un premier exemple, un utilisateur (li) souhaite réserver un Lieu qui est un court de tennis. Pour cela, ledit utilisateur (li) se connecte via un terminal (2m) de manière classique au serveur distant (3) à travers un réseau de télécommunication (9). Ledit 20 serveur (3) contient toutes les bases de données correspondant aux données personnelles dudit utilisateur (li) ainsi que toutes les données de tous les Lieux qui sont dans notre exemple des courts de tennis. Dès que le terminal (2m) est connecté au serveur (3), le processeur 25 (32) dudit serveur (3) affiche via l'interface réseau (31) et à travers le réseau de télécommunication (9), un menu sur l'écran du terminal (2m) afin de demander à l'utilisateur (li) dudit terminal (2m) de s'identifier, par exemple en tapant son identifiant et son mot de 30 passe. 4 2909203 5 Dans un mode de réalisation particulier, l'identification de l'utilisateur (li) est faite par un lecteur de badges ou de cartes à puce du terminal (2m). Dés que l'utilisateur (li) est identifié, ledit 5 processeur (32) affiche, à partir de la base de données des Utilisateurs (34) les paramètres principaux dudit utilisateur (li) comme par exemple son nom, prénom, adresse, classement, etc. Dans un mode de réalisation particulier, ledit 10 processeur (32) affiche à partir de la base de données des Registres des Utilisateurs de réservation des Joueurs (33) toutes les réservations déjà effectuées par ledit utilisateur (li). Dans un autre mode de réalisation, ledit processeur 15 (32) affiche à partir de la base de données des Occupations des Lieux (37) tous les courts disponibles sur ce serveur. La base de données des Occupations des Lieux (37) comprend pour chacun des courts, son niveau d'occupation : occupé, libre, option, réservé, etc. 20 Avantageusement, ledit processeur (32) affiche à partir de la base de données des Occupations des Lieux (37) tous les courts Occupés. Avantageusement, les noms et les photos des joueurs ayant réservés chaque Lieu sont affichés sur l'écran du 25 terminal (2m). Avantageusement, le nombre et/ou tous les noms des joueurs correspondant à chaque réservation, sont affichés sur l'écran du terminal (2m). Avantageusement, toutes les réservations faites par 30 ledit utilisateur (li) sont affichées avec une couleur personnalisée pour ledit utilisateur (li). Pour réserver un court, un utilisateur (li) se positionne alors, par exemple avec la souris du terminal 2909203 6 (2m), sur la case correspondant au court, au _jour et à l'heure qu'il a choisis. Le processeur (32) contrôle alors que les paramètres dudit ledit utilisateur (li) lui permettent 5 bien de réserver ledit court à ce moment de telle journée. Pour cela, le processeur (32) lit d'une part la base de données des Critères des Lieux (36) qui contient pour chacun des courts, les emplacements, les 10 disponibilités génériques comme par exemple court couvert, sol en terre battue, gazon, réservé aux professionnels, réservé à tel classement, etc., et d'autre part, les paramètres dudit utilisateur: (li) à partir de la base de données des Utilisateurs (34). 15 Avantageusement, ladite base de données des Utilisateurs (34) contient la formule d'abonnement en tant que membre du club comme par exemple : • La période d'utilisation o Formule été 20 o Formule année scolaire o Formule saison o Etc. • Le lieu car certaines formules ne sont valables que sur certains courts 25 • Le type o Abonnement périodique o Abonnement à la carte o Forfait de quelques heures Si les paramètres dudit utilisateur (li) et les 30 Critères du Court sont compatibles, le réservation dudit court est confirmée par le processeur (32) qui envoie un accusé de réception positif à la base de données des Registres des Utilisateurs de réservation des Joueurs 2909203 7 (33) ainsi qu'à la base de données des Occupations des Lieux (37). Ledit processeur (32) met alors à jour et synchronise ladite base de données des Registres des Utilisateurs de réservation des Joueurs (33), ainsi que 5 ladite base de données des Occupations des Lieux (37) qui précise que tel court est Réservé par ledit utilisateur (li), tel jour pour tel créneau horaire. Dans un autre mode de réalisation, un utilisateur téléphone à un administrateur de ladite base de données 10 des Occupations des Lieux (37) et demande audit administrateur de lui réserver un court pour tel jour et à telle heure. Dans un autre mode de réalisation, un administrateur de ladite base de données des Occupations 15 des Lieux (37) modifie l'état d'occupation d'un court par blocs comme par exemple, le court est réservé occupé pour une compétition à toutes les heures pendant quatre jours. Dans un autre exemple, un administrateur de ladite base de données des Occupations des Lieux (37) modifie 20 l'état d'occupation d'un court pour telle heure, tous les jours de la semaine. A tout moment, un utilisateur (li, lj, lk, etc.) peut annuler une réservation qu'il a effectuée. Dans ce cas, la réservation est supprimée par le processeur (32), 25 qui synchronise ladite base de données des Registres des Utilisateurs de réservation des Joueurs (33) et ladite base de données des Occupations des Lieux (37). Dans un autre mode de réalisation, un utilisateur (lo) utilise un terminal (7r) pour faire ladite 30 réservation. Les terminaux (4r, 7t, etc.) sont connectés au serveur de données (3) par le réseau local (8). 2909203 8 Dans un autre exemple, un autre utilisa:eur (lj) souhaite rechercher un ou des partenaires de jeux pour faire une partie de tennis. Pour faire cela, ledit utilisateur (lj) se connecte 5 via un terminal (2n) de manière classique au serveur distant (3). Dès que le terminal (2n) est connecté au serveur (3), le processeur (32) dudit serveur (3) affiche un menu sur l'écran du terminal (2n) afin de demander à son utilisateur (1j) de s'identifier. 10 Ledit processeur (32) affiche, à partir de la base de données des Utilisateurs (34) les paramètres principaux dudit utilisateur (lj), toutes les réservations déjà effectuées par ledit utilisateur (lj), ainsi que tous les courts disponibles sur ce serveur à 15 partir de la base de données des Occupations des Lieux (37). Pour rechercher un partenaire, ledit utilisateur (lj) choisi l'option recherche de partenaires et se positionne sur la case correspondant au court, au jour et 20 à l'heure qu'il envisage. Avantageusement, ledit utilisateur (lj) précise combien de partenaires il recherche, s'il souhaite jouer contre un homme ou une femme, en simple ou er,, double, etc. 25 Le processeur (32) contrôle que les paramètres dudit ledit utilisateur (li) lui permettent bien de rechercher un ou des partenaires pour ledit court à ce moment de telle journée. Pour cela, le processeur (32) lit la base de données des Critères des Lieux (36) et les 30 paramètres dudit utilisateur. (lj) à partir de la base de données des Utilisateurs (34). Si les paramètres dudit utilisateur (lj) et les Critères du Court: sont compatibles, la recherche de partenaires est acceptée par 2909203 9 le processeur (32) et ledit court est réservé en Option recherche de partenaires . Ledit processeur (32) met à jour et synchronise alors ladite base de données des Registres des Utilisateurs de réservation des Joueurs 5 (33), ainsi que la base de données des Occupations des Lieux (37). Avantageusement, les courts qui sont occ-ipés avec l'Option recherche de partenaires , apparaissent dans un autre couleur que les courts occupés ou libres. 10 Dans une mise en œuvre particulière, le processeur (32) lit la base de données des Préférences des Joueurs (35) qui correspond aux préférences de chaque joueur comme par exemple les courts sur lesquels il souhaite jouer dans un ordre de préférence. 15 Avantageusement, ladite base de données des Préférences des Joueurs (35) contient la liste des partenaires de préférence avec qui il souhaite jouer en priorité. Avantageusement, ladite base de données des 20 Préférences des Joueurs (35) contient pour chaque joueur, les jours et les horaires préférés. A partir des informations de ladite base de données des Préférences des Joueurs (35), le processeur (32) affiche en priorité les courts préférés dudit utilisateur 25 (2n) afin de simplifier audit utilisateur (2n) la sélection des courts pour le jour sélectionné. Avantageusement, ledit utilisateur (2n) sélectionne un ou certains utilisateurs parmi ses partenaires préférés. 30 Avantageusement, ledit utilisateur (2n) sélectionne un partenaire qui ne se trouve pas dans sa liste des partenaires privilégiés mais dans uns liste de joueurs qui ont un niveau de jeu équivalent. 2909203 10 Dans un mode de réalisation particulier, dès que l'Option recherche de partenaires est effectuée, le processeur (32) envoie automatiquement un message électronique de type mèl (email) ou SMS, sur _e ou les 5 terminaux des partenaires préférés dudit utilisateur (2n). Par exemple, si un partenaire préféré dudit utilisateur (2n) possède un téléphone portable (5p), le processeur (32) envoie automatiquement un SMS audit 10 terminal (5p) en indiquant que ledit utilisateur (2n) souhaite jouer avec lui tel jour à telle heure sur tel court. Avantageusement, le processeur (32) complète le SMS envoyé avec une demande de réponse par une manoeuvre 15 simple sur son téléphone. L'utilisateur dudit terminal (5p) accepte ou refuse alors cette invitation. Dans un autre mode de réalisation, si un partenaire préféré dudit utilisateur (2n) possède un terminal de type PC, le processeur (32) envoie automatiquement un mèl 20 (email) au terminal dudit partenaire en indiquant que ledit utilisateur (2n) souhaite jouer avec lui tel jour à telle heure sur tel court. Le processeur (32) complète ledit mèl (email) envoyé avec une demande de réponse par une manoeuvre simple sur son PC. L'utilisateur dudit PC 25 accepte ou refuse alors cette invitation. Si l'invitation est acceptée, le processeur (32) confirme la réservation, met à jour et synchronise ladite base de données des Registres des Utilisateurs de réservation des Joueurs (33) pour les deux utilisateurs 30 (2n) et (5p), ainsi que la base de données des Occupations des Lieux (37) qui passe de l'état Option recherche de partenaires à l'état Réservé. 2909203 11 Dans un autre mode de réalisation, l'interface (31) est relié à un réseau local (8) lui même relié à des terminaux (7r, 7t, etc.) tels que des PC ou des bornes multimédias locales. Lesdits terminaux (7) servent ainsi 5 de terminaux de saisie et de consultation des bases de données du serveur (3). Dans un mode de réalisation particulier, l'accès aux courts de tennis est contrôlé par un lecteur de badges magnétique ou à carte à puce (9u, ... 9z) connecté 10 sur ledit réseau local (8) par exemple au niveau de la porte d'entrée de chaque court. Seuls les uti:_isateurs (1) qui ont réservés le court peuvent accéder au court. Ledit utilisateur (li) s'identifie grâce au lecteur de badges (9u) correspondant au court qu'il a réservé, et le 15 processeur (32) vérifie via ladite base de données des Occupations des Lieux (37) et ladite base de données des Utilisateurs (34) si ledit utilisateur (li) peut pénétrer sur ledit court contrôlé par le lecteur de badges (9u). L'accès à un Lieu est conditionné à la lecture du badge 20 Utilisateur, aux informations de ladite base de données des Occupations des Lieux (37) et aux informations de ladite base de données des Critères des Lieux (36). Avantageusement, l'accès audit court réservé est possible uniquement dans une plage horaire allant par 25 exemple de 10mn avant et lOmn après leur créneau. horaire de réservation précisé dans ladite base de données des Occupations des Lieux (37). Un autre exemple concerne l'utilisation dudit procédé pour réserver des départs sur un parcours de 30 golf. Dans ce cas, ladite base de données des Utilisateurs concerne les golfeurs, ladite base de données des Registres des Utilisateurs est utilisée pour enregistrer les heures de départs, ladite base de données 2909203 12 des Critères des Lieux décrit l'ensemble des parcours de golf avec ses caractéristiques, et ladite base de données des Occupations des Lieux précise pour tous les parcours de golf chaque occupation de chaque départ à partir de 5 chaque trou. L'invention présente n'est pas limitée à l'incarnation préférée décrite en ceci et montrée sur la figure ci-jointe, les changements peuvent être faits ou des équivalents employés sans pâtir de la portée de 10 l'invention. REVENDICATIONS 1 - Procédé pour la synchronisation de bases de données hétérogènes comprenant un processeur (32) et au moins une base de données des Utilisateurs (34), au moins une base de données des Registres des Utilisateurs (33), au moins une base de données des Critères des Lieux (36), et au moins une base de données des Occupations des Lieux (37), caractérisé en ce que l'on procède, avant la modification de certaines données de ladite base de données des Occupations des Lieux (37) et la modification de certaines données de ladite base de données des Registres des Utilisateurs (33), à un traitement de vérification de la compatibilité de certaines informations de ladite base de données des Critères des Lieux (36) et de ladite base de données des Utilisateurs (34), ledit traitement de vérification étant fait par ledit processeur (32) qui envoie un accusé de réception positif à ladite base de données des Registres des Utilisateurs {33) ainsi qu'à ladite base de données des Occupations des Lieux (37). 2 - Procédé pour la synchronisation de bases de données 20 hétérogènes selon la revendication 1, caractérisé en ce que ladite base de données des Utilisateurs (34) est complétée par une base de données des Préférences (35) desdits Utilisateurs. 3 - Procédé pour la synchronisation de bases de données 25 hétérogènes selon l'une des revendications précédentes caractérisé en ce que certaines données de ladite base de données des Occupations des Lieux (37) sont modifiées par blocs de données par ledit processeur (32). 30 4 - Procédé pour la synchronisation de bases de données hétérogènes selon l'une des revendications précédentes 2909203 14 caractérisé en ce que certaines données de ladite base de données des Occupations des Lieux (37) sont modifiées via ledit processeur (32) par un Utilisateur, en fonction des paramètres de ladite base de données des Registres des Utilisateurs (33). 5 5 - Procédé pour la synchronisation de bases de données hétérogènes selon l'une des revendications précédentes caractérisé en ce que certaines données de ladite base de données des Occupations des Lieux (37) sont modifiées via ledit 10 processeur (32) par un Utilisateur, en fonction des paramètres de ladite base de données des Critères des Lieux (36). 6 - Procédé pour la synchronisation de bases de données hétérogènes selon l'une des revendications précédentes 15 caractérisé en ce que ladite base de données des Occupations des Lieux (37) est synchronisée par ledit processeur (32) avec ladite base de données des Registres des Utilisateurs (33). 7 - Procédé pour la synchronisation de bases de données hétérogènes selon l'une des revendications précédentes caractérisé en ce qu'un utilisateur de ladite base de données des Utilisateurs (33) prend une option Réservée pour Recherche de partenaires dans ladite base de données des Occupations des Lieux (37). 8 - Procédé pour la synchronisation de bases de données hétérogènes selon la revendication 7 caractérisé en ce qu'un mèl (email) est envoyé par ledit processeur (32) sur les terminaux des partenaires potentiels suite à ladite prise d'option Réservée pour Recherche de partenaires dans ladite base de données des Occupations des Lieux (37). 2909203 15 9 - Procédé pour la synchronisation de bases de données hétérogènes selon l'une des revendications 7 et 8 caractérisé en ce qu'un SMS est envoyé par ledit processeur (32) sur les terminaux des partenaires potentiels suite à ladite prise 5 d'option Réservée pour Recherche de partenaires dans ladite base de données des Occupations des Lieux (37). 10 - Système de synchronisation de bases de données hétérogènes comportant un serveur pour la mise en œuvre du 10 procédé conforme à l'une au moins des revendications précédentes, caractérisé en ce qu'il comporte au moins un réseau local sur lequel est connecté au moins un lecteur de badges. 15 11 - Système de synchronisation de bases de données hétérogènes selon la revendication 10, caractérisé en ce qu'il comporte en outre au moins un terminal de saisie et de consultation connecté audit réseau local. 20 12 - Système de synchronisation de bases de données hétérogènes selon l'une des revendications 10 et 11, caractérisé en ce que l'accès à un Lieu est conditionné à la lecture d'un badge Utilisateur, aux informations de ladite base de données des Occupations des Lieux et aux informations 25 de ladite base de données des Critères des Lieux.