La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

85 J. AKOKA &I.WATTIAU Conceptualisation : illustration PERSON (ssn, name, address) EMPLOYEE(ssn, name, salary, hired-date) MANAGER(ssn, rank, promotion-date,

Présentations similaires


Présentation au sujet: "85 J. AKOKA &I.WATTIAU Conceptualisation : illustration PERSON (ssn, name, address) EMPLOYEE(ssn, name, salary, hired-date) MANAGER(ssn, rank, promotion-date,"— Transcription de la présentation:

1 85 J. AKOKA &I.WATTIAU Conceptualisation : illustration PERSON (ssn, name, address) EMPLOYEE(ssn, name, salary, hired-date) MANAGER(ssn, rank, promotion-date, deptno) CUSTOMER(ssn, custid, name, credit) DEPARTMENT(deptno, dept-name, location) PRODUCT(pronum, description) PRICE(pronum, minprice, maxprice) ORDER(ordid, order-date, prodid, custid) CARRIER(carrier-id, name, address) PROJECT(pronum, deptno, budget) WORK-FOR(ssn, deptno, start-date) CAN-PRODUCE(deptno, pronum, unit-cost) SHIPMENT(pack#, ordid, ship-date, carrier-id). Le schéma relationnel initial

2 86 J. AKOKA &I.WATTIAU Etape 1 : - identification des entités PERSON, EMPLOYEE, MANAGER, CUSTOMER, DEPARTMENT, PRODUCT, PRICE et ORDER. - suspicion dhomonymes ou dhéritages entre les clés de PERSON, EMPLOYEE, MANAGER et CUSTOMER dune part et PRICE et PRODUCT dautre part. - recherche dun identifiant pour la table relationnelle CARRIER

3 87 J. AKOKA &I.WATTIAU Résultat de la première étape : les lignes discontinues représentent les homonymes ou les liens de généralisation soupçonnés : PERSON EMPLOYEEMANAGER CUSTOMER PRICE PRODUCT DEPARTMENT ORDER

4 88 J. AKOKA &I.WATTIAU Etape 2 : Confirmation des relations dinclusion suivantes PERSON EMPLOYEE MANAGER et PERSON CUSTOMER Infirmation des autres Présomption d'associations entre entités : - EMPLOYEE (ou MANAGER ou CUSTOMER ou PERSON) et DEPARTMENT, - deux associations entre DEPARTMENT et PRODUCT, - une association 1-1 entre PRICE et PRODUCT, - deux associations entre DEPARTEMENT et PRICE, - ORDER et une entité à déterminer Confirmation de Carrier-id comme identifiant de la table CARRIER

5 89 J. AKOKA &I.WATTIAU Résultat de la deuxième étape : (les ovales représentent des associations et les flèches des liens de généralisation) : PERSON EMPLOYEE MANAGER CUSTOMER PRICE PRODUCT DEPARTMENT ORDER work-for project can-produce ?? ? ? ?? 1 1 shipment ?

6 90 J. AKOKA &I.WATTIAU Etape 3 : L'application des règles indiquées ci-dessous nous permet de confirmer les associations suivantes : work-for est une association reliant uniquement les entités EMPLOYEE et DEPARTMENT. a est une association 1-1 entre les entités PRODUCT et PRICE L'association can-produce entre DEPARTMENT et PRODUCT est consolidée. L'association shipment nous conduit à définir une entité organisationnelle appelée PACK. L'association project existant entre DEPARTMENT et PRODUCT reflète l'existence d'un homonyme contrairement à celle entre DEPARTMENT et PRICE. L'analyse du DML confirme lhomonymie entre la colonne Pronum de la table PROJECT et la colonne Pronum de la table PRICE ou PRODUCT. Le même raisonnement peut être appliqué à l'autre association project.

7 91 J. AKOKA &I.WATTIAU Résultat de la troisième étape : PERSON EMPLOYEE MANAGER CUSTOMER PRICE PRODUCT DEPARTMENT ORDER work-for project can-produce ? ? 1 1 shipment PACK

8 92 J. AKOKA &I.WATTIAU Itération de l'étape 2 : Association project entre l'entité DEPARTMENT et une autre entité à découvrir Itération de l'étape 3 : Confirmation de la nature de l'entité PROJECT (faible). Résultat :

9 93 J. AKOKA &I.WATTIAU Etape 4 : Détection de clés étrangères dans les tables relationnelles MANAGER, ORDER et SHIPMENT. Nous obtenons alors les associations 1 : N potentielles. Résultat : le symbole --- représente une clé étrangère potentielle.

10 94 J. AKOKA &I.WATTIAU Etape 5 : Confirmation de toutes les clés étrangères. L'association shipment doit être transformée en entité.

11 95 J. AKOKA &I.WATTIAU La désoptimisation du schéma physique Principe : Examiner les spécifications DDL pour suspecter des opérations doptimisation Scanner les spécifications DML pour confirmer ou infirmer ces opérations doptimisation Sil y a confirmation, vérifier dans les données pour valider les restructurations Réitérer le processus tant quil y a des opérations possibles Présenter le schéma logique restructuré au concepteur pour validation Opérations : jointure, projection, restriction, aplatissement.

12 96 J. AKOKA &I.WATTIAU Lopération de jointure Principe : autorise la construction des relations formées par la concaténation des tuples de deux relations existantes selon le prédicat de jointure, incluant le plus souvent une clé étrangère. Exemple : Invoice(Invoice#,Customer#,Amount,Date) Customer(Customer#,Customer_name,Address) Incust(Invoice#,Customer#,Amount,Date,Customer_name,Address) Provoque une dénormalisation du schéma (3FN->2FN,2FN->1FN) 4 cas de jointure

13 97 J. AKOKA &I.WATTIAU Jointure : cas 1 La jointure est faite sur un attribut clé primaire des deux tables : R1(K, C1,C2,...,Cn) & R2(K, D1,D2,...,Dm) => R(K, C1,C2,...,Cn,D1,D2,...,Dm) introduit un grand nombre de valeurs nulles pas de dénormalisation : si R1 et R2 sont en 3FN, R est en 3FN Exemple : Employee(Employee_number,Rank,Salary) Career(Employee_number,Arrival_date,First_career_job,Starting_sal)

14 98 J. AKOKA &I.WATTIAU Jointure : cas 2 La jointure est faite sur un attribut clé primaire dune table et clé étrangère de lautre : R1(K1, C1,C2,...,Cn) & R2(K2, D1,D2,...,Dm,K1) => R(K2, C1,C2,...,Cn,D1,D2,...,Dm,K1) génère des données redondantes dénormalisation : R contient des dépendances fonctionnelles entre non- clés Exemple : Invoice(Invoice#,Customer#,Amount,Date) Customer(Customer#,Customer_name,Address)

15 99 J. AKOKA &I.WATTIAU Jointure : cas 3 La jointure est faite sur un attribut clé primaire dune table et un attribut partie de clé de lautre table : R1(K1, C1,C2,...,Cn) & R2(K1,K2, D1,D2,...,Dm) => R(K1,K2, C1,C2,...,Cn,D1,D2,...,Dm) génère des données redondantes dénormalisation : R contient des dépendances fonctionnelles entre partie de clé et non-clés (C1,C2,..,Cn) Exemple : Student(Student#,Name,Level) Result(Student#,Course#,Grade)

16 100 J. AKOKA &I.WATTIAU Jointure : cas 4 La jointure est faite sur deux attributs non clés des deux tables : R1(K1, C1,C2,...,Cn,NK) & R2(K2, D1,D2,...,Dm,NK) => R(K1,K2, C1,C2,...,Cn,D1,D2,...,Dm,NK) rare si R1 et R2 sont en 3FN, R contient des données redondantes il existe des dépendances fonctionnelles entre une partie de clé (K1) et des non clés (C1,C2,...,Cn,NK). Exemple : joindre les deux tables suivantes sur la condition Headquarter- city=Production-city Supplier(Supplier#,Name,Address,Headquarter-city) Part(Part#,Part-name,Production-city)

17 101 J. AKOKA &I.WATTIAU Linversion de lopération de jointure Principe : supprimer la jointure en la remplaçant par les deux relations dorigine cest une opération de projection Détection: DDL : très peu (ou pas) de clauses NOT NULL DML : la plupart des requêtes sont des projections sur certains attributs, le plus souvent sur les mêmes attributs. Données : on détecte des dépendances fonctionnelles et des valeurs nulles

18 102 J. AKOKA &I.WATTIAU Les règles de rétro-conception La règle Ru1 correspondant au cas 1 peut être paraphrasée comme suit : Soit la relation R(K, C1,C2,...,Cn,D1,D2,...,Dm) SI il ny a pas dattribut Ci ou Di défini avec NOT NULL ET/OU il y a plusieurs requêtes SQL avec les clauses SELECT,WHERE,ORDER BY et GROUP BY portant uniquement sur K et les Ci ET/OU il y a plusieurs requêtes SQL avec les clauses SELECT,WHERE,ORDER BY et GROUP BY portant uniquement sur K et les Dj ET/OU il ny a pas de tuple contredisant la D.F. K->C1,C2,...,Cn ET/OU il ny a pas de tuple contredisant la D.F. K->D1,D2,...,Dm ET/OU il y a des tuples ayant des valeurs nulles pour tous les Ci ET/OU il y a des tuples ayant des valeurs nulles pour tous les Dj ALORS MeRCI propose la décomposition de R en deux tables R1(K,C1,C2,...,Cn) et R2(K,D1,D2,...,Dm)

19 103 J. AKOKA &I.WATTIAU Lopération de projection Principe : simplifie une relation en réduisant sa largeur. permet de renommer des attributs et/ou de les permuter dans une table. Exemple : Employee(Employee#,Rank,Salary,Arrival-date,First-caree-job,Start-sal) Deux projections peuvent être faites conduisant aux tables suivantes : Payroll(Employee#,Rank,Salary) Career(Employee#,Arrival-date,First-caree-job,Start-sal) Remarques : Pas de perte de données Conserve les clés Ne provoque pas de dénormalisation

20 104 J. AKOKA &I.WATTIAU Linversion de lopération de projection Principe : consiste à supprimer les tables obtenues par projection et à les remplacer par la table initiale contenant tous les attributs Détection: DDL : plusieurs relations ont des attributs clés primaires ou uniques avec le même nom et le même type de données DML : certaines requêtes SQL sont des jointures entre les clés des deux relations. Données : les attributs clés qui ont les mêmes noms ont un grand nombre de valeurs communes

21 105 J. AKOKA &I.WATTIAU Les règles de rétro-conception Soit les relations R1(K1, C1,C2,...,Cn) et R2(K2,D1,D2,...,Dm) SI K1 et K2 ont le même nom ET/OU K1 et K2 ont le même type de données ET/OU il y a une ou plusieurs requêtes SQL dont la clause WHERE contient une égalité ou une comparaison avec IN entre K1 et K2 ET/OU lintersection des valeurs de K1 et K2 contient un grand nombre de valeurs communes ALORS MeRCI propose le regroupement de R1 et R2 en une relation R(K1,C1,C2,...,Cn,D1,D2,...,Dm)

22 106 J. AKOKA &I.WATTIAU Lopération de restriction Principe : forme une relation dont les tuples sont filtrés grâce à un prédicat ou condition de restriction Exemple : La relation Customer (Customer#, Customer-name, Address, Turnover) peut être restreint en deux relations Large_Customer (Customer#, Customer-name, Address, Turnover) et Small_Customer (Customer#, Customer-name, Address, Turnover) selon le montant du Turnover (inférieur ou supérieur à une borne) Remarques : Pas de perte de données Ne provoque pas de dénormalisation

23 107 J. AKOKA &I.WATTIAU Linversion de lopération de restriction Principe : supprimer les tables obtenues par restriction et à les remplacer par la table initiale contenant tous les tuples (opération dunion). Détection: DDL : plusieurs relations ont le même schémas. Les attributs clés primaires ou uniques sont définis par le même type de données. Les autres attributs ont aussi le même nom, le même type, et éventuellement les mêmes contraintes (FOREIGN KEY,CHECK, etc...) DML : certaines requêtes SQL sont des unions entre les clés de deux relations (ou plus). Données : les attributs clés qui ont les mêmes noms ont un ensemble de valeurs disjointes.

24 108 J. AKOKA &I.WATTIAU Les règles de rétro-conception Soit les relations R1(K1, C1,C2,...,Cn) et R2(K2,D1,D2,...,Dm) SI K1 et K2 ont le même nom ET/OU K1 et K2 ont le même type de données ET/OU Ci et Dj ont le même nom et/ou le même type de données ET/OU il y a une ou plusieurs requêtes SQL avec un opérateur UNION entre deux SELECT portant respectivement sur R1 et R2 et une clause WHERE contenant une condition sur K1 liée par OR à la même condition sur K2 ET/OU lintersection des valeurs de K1 et K2 est vide ALORS MeRCI propose de transformer R1 et R2 en une relation unique R(K1,C1,C2,...,Cn)

25 109 J. AKOKA &I.WATTIAU Lopération daplatissement Principe : linformation peut être représentée comme des valeurs dattributs, des noms dattributs ou des noms de tables. lopérateur daplatissement transporte linformation dun niveau de représentation à un autre : des valeurs aux attributs. ce nest pas un opérateur relationnel. sapplique uniquement aux attributs à type discret et ayant peu de valeurs - aplatit le type de champ dans la structure Exemple : La relation Courseplanning (Course#, Course-Day, Course-Name, Course-Hour) peut être aplatie en utilisant le jour : Course (Course#, Course-Name, Monday-House, Tuesday-Hour, Wednesday-Hour, Thursday-Hour, Friday-Hour, Saturday-Hour ). Réduit la clé Ne provoque pas de dénormalisation

26 110 J. AKOKA &I.WATTIAU Linversion de lopération daplatissement Principe : remplacer plusieurs colonnes ayant le même type par un attribut décrivant ce type. Linverse de laplatissement de R(K,C1,C2,...,Cn, D1,D2,...,Dm) sur les colonnes Ci remplace R par R1(K,K2, C,D1,D2,...Dm). Détection: DDL : la table aplatie a plusieurs colonnes de même type avec une partie de nom commune DML : certaines requêtes SQL ont des clauses WHERE avec le même prédicat sur les différentes colonnes du même type Données : les valeurs des colonnes qui ont le même type sont identiques.

27 111 J. AKOKA &I.WATTIAU Les règles de rétro-conception Soit la relation R(K, C1,C2,...,Cn,D1,D2,...,Dm) SI les Ci ont une partie du nom commune ET/OU les Ci ont le même type de données ET/OU il y a une ou plusieurs requêtes SQL avec une clause WHERE ou SET contenant une condition identique sur les différentes colonnes Ci ET/OU lintersection des valeurs des Ci contient plusieurs valeurs communes et une plage de valeurs communes ALORS MeRCI propose de transformer R en R1(K,K1,C,D1,D2,...,Dm)

28 112 J. AKOKA &I.WATTIAU American_countries(country_code/char(6);country_name/char(30),restrictiveness/char(30)) Arrival(flight_number/char(6);airport_code/char(6)) Asian_countries(country_code/char(6);country_name/char(30),restrictiveness/char(30)) Departure(flight_number/char(6);airport_code/char(6)) European_countries(country_code/char(6);country_name/char(30),restrictiveness/char(30)) Fares(flight_number/char(6),type_code/char(4),conc_class/char(30),single/decimal(6,2), return/decimal(6,2)) Flights(flight_number/char(6);aircraft/char(30),distance/integer,airline_code/char(3), airline_name/char(30)) Int_Stops(flight_number/char(6),airport_code/char(6);airport_name/char(30),country_code/char(6), stop_number/integer) Restrictions(country_code/char(4), visa_type/char(30); conditions/text) Savers(saver_code/char(3); saver_name/char(30), saver_conditions/text) Season(season_code/char(1); season_name/char(30), start_date/date, end_date/date) Seat_Classes(seat_class_code/char(1); seat_class_name/char(30)) Times(flight_number/char(6);mon_dep/decimal(4,2),mon_arr/decimal(4,2),tue_dep/decimal(4,2), tue_arr/decimal(4,2),wed_dep/decimal(4,2),wed_arr/decimal(4,2), thu_dep/decimal(4,2),thu_arr/decimal(4,2),fri_dep/decimal(4,2), fri_arr/decimal(4,2),sat_dep/decimal(4,2),sat_arr/decimal(4,2), sun_dep/decimal(4,2),sun_arr/decimal(4,2)) Types(type_code/char(4); seat_class_code/char(1), saver_code/char(3), season_code/char(1)) Désoptimisation : un exemple

29 113 J. AKOKA &I.WATTIAU * (1) insert a new flight (that means, the flight, its times, its stops and its fares) * (2) delete a flight (that means, the flight, its times, its stops and its fares) * (3) modify times of a flight * (4) select the fares for each type for each airline about flights flying from airport A to airport B * (5) select the times of a given flight * (6) select the intermediate stops of a flight * (7) select the restrictiveness for a given country * (8) list the different countries and their continent names * (9) list the different airports and their respective countries * (10) list the different airlines characteristics * (11) select the different flights realized with a given aircraft * (12) what is the distance covered by a given flight Liste des requêtes principales

30 114 J. AKOKA &I.WATTIAU X signifie que la règle peut être appliquée à la table o signifie que la table vérifie certaines conditions de déclenchement de la règle - signifie la règle ne sapplique pas à la table Application des règles aux tables de lexemple

31 115 J. AKOKA &I.WATTIAU Airline (airline_code, airline_name) Airport(airport_code; airport_name, country_code) Countries(country_code/char(6);country_name/char(30),restrictiveness/char(30), continent) Dep_arr(flight_number; airport_dep, airport_arr) Fares(flight_number/char(6),type_code/char(4),conc_class/char(30),single/decimal(6,2), return/decimal(6,2)) Flights(flight_number, aircraft, distance) Int_Stops(flight_number, airport_code; stop_number) Restrictions(country_code/char(4), visa_type/char(30); conditions/text) Savers(saver_code/char(3); saver_name/char(30), saver_conditions/text) Season(season_code/char(1); season_name/char(30), start_date/date, end_date/date) Seat_Classes(seat_class_code/char(1); seat_class_name/char(30)) Times(flight_number/char(6),dep_arr;time) Types(type_code/char(4); seat_class_code/char(1), saver_code/char(3), season_code/char(1)) Le schéma relationnel après la première itération de lensemble de règles

32 116 J. AKOKA &I.WATTIAU Airline (airline_code, airline_name) Airport(airport_code; airport_name, country_code) Countries(country_code/char(6);country_name/char(30),restrictiveness/char(30), continent) Fares(flight_number/char(6),type_code/char(4),conc_class/char(30),single/decimal(6,2), return/decimal(6,2)) Flights(flight_number, aircraft, distance,airport-dep,airport-arr) Int_Stops(flight_number, airport_code; stop_number) Restrictions(country_code/char(4), visa_type/char(30); conditions/text) Savers(saver_code/char(3); saver_name/char(30), saver_conditions/text) Season(season_code/char(1); season_name/char(30), start_date/date, end_date/date) Seat_Classes(seat_class_code/char(1); seat_class_name/char(30)) Times(flight_number/char(6),dep_arr;time) Types(type_code/char(4); seat_class_code/char(1), saver_code/char(3), season_code/char(1)) Le schéma relationnel après une seconde itération de lensemble de règles

33 117 J. AKOKA &I.WATTIAU Savers saver-code saver-name saver-conditions Seat Classes seat-class-code seat-class-name Types type-code Seasons season-code season-name start-date end-date Fares conc-class single return Flights flight-number aircraft distance airport-dep airport-arr Airline airline-code airline-name Times day time Airports airport-code airport-name Countries country-code country-name continent Visa visa-type restrictions conditions m n 1 n Int-Stops stop-number m n m n m n 1 n n m 1 n 1 n n 1 Le schéma conceptuel résultant

34 118 J. AKOKA &I.WATTIAU 4.5. Rétroconception des bases multidimensionnelles Objectif : extraire le schéma conceptuel dune base de données multidimensionnelles à partir dun schéma logique/physique Raisons : la modélisation dune base de données multidimensionnelle joue un rôle important dans la conception dun datawarehouse le schéma multidimensionnel dun datawarehouse offre une vue intégrée des différentes sources de données opérationnelles le schéma multidimensionnel est dépendant des besoins des utilisateurs de la disponibilité des données des systèmes opérationnels de la structure de ces données

35 119 J. AKOKA &I.WATTIAU Raisons (suite) : la plupart des projets de datawarehouse utilise une approche incrémentale on commence par un prototype offrant certaines fonctionnalités et utilisant un ensemble de données puis le prototype est affiné suivant les besoins (changeants) des utilisateurs les besoins des utilisateurs changent nécessite une adaptation et une évolution du schéma par conséquent un coût de maintenance élevé pour offrir une flexibilité et une réutilisation du schéma, le modèle doit être spécifié à un niveau conceptuel : ce nest pas le cas des datawarehouses actuels

36 120 J. AKOKA &I.WATTIAU Caractéristiques des systèmes multidimensionnels Les concepts dOLAP: consolidation : les données sont agrégées selon des dimensions hiérarchisées drill-down : une donnée agrégée est visualisée à un niveau de détail choisi par lutilisateur slicing and dicing : les données sont visualisées selon différentes perspectives (par exemple vente par région et canal de distribution) gestion des alertes et des seuils : des codes de couleur sont utilisés pour attirer lattention sur certaines données

37 121 J. AKOKA &I.WATTIAU Caractéristiques des applications OLAP : un appel à de très grands volumes de données la présence des données agrégées la comparaison des données agrégées hiérarchiques et dans le temps la présentation des données selon différentes perspectives la réalisation de calculs complexes la présentation des données sous forme de tableaux croisés facilement manipulables la consultation des données sans les modifier.

38 122 J. AKOKA &I.WATTIAU Architecture dun datawarehouse

39 123 J. AKOKA &I.WATTIAU Les modèles de données dun datawarehouse

40 124 J. AKOKA &I.WATTIAU Les modèles logiques/physiques - les concepts utilisés

41 125 J. AKOKA &I.WATTIAU Le modèle en étoile

42 126 J. AKOKA &I.WATTIAU Le modèle en flocon

43 127 J. AKOKA &I.WATTIAU La rétroconception à laide de MeRCI -M

44 128 J. AKOKA &I.WATTIAU Les étapes du processus

45 129 J. AKOKA &I.WATTIAU La modélisation des règles de rétroconception Un méta-modèle du schéma conceptuel cible Un méta-modèle de la base de données multidimensionnelle Des règles de production qui opèrent sur les deux méta-modèles auxquelles on associe des facteurs de certitude

46 130 J. AKOKA &I.WATTIAU Le méta-modèle de la base multidimensionnelle Objet nom Dimension/Relation Relationrelie 0,n 2,2 Dimension Variable mono dimensionnelle Variable multi dimensionnelle fait varier 0,n 1,1 comporte 0,n 2,n

47 131 J. AKOKA &I.WATTIAU Mapping entre les deux méta- modèles

48 132 J. AKOKA &I.WATTIAU Les règles de rétroconception Règle de suspicion : une variable multidimensionnelle se rapportant à plus de deux dimensions peut devnir un attribut dune association entre les entités désignées par ces dimensions. Règle de consolidation : les attributs des relations binaires M:N sont consolidés sil existe plus dun attribut non identifiant à la relation Règle de confirmation : une dimension devient lidentifiant dune entité que lon crée

49 133 J. AKOKA &I.WATTIAU Un exemple

50 134 J. AKOKA &I.WATTIAU Application des règles de létape 1

51 135 J. AKOKA &I.WATTIAU Application des règles de létape 2

52 136 J. AKOKA &I.WATTIAU Application des règles de létape 3

53 137 J. AKOKA &I.WATTIAU Application des règles de létape 4

54 138 J. AKOKA &I.WATTIAU Approches "manuelles" Approches algorithmiques en établissant des hypothèses simplificatrices, ou en définissant des pré-traitements "manuels", les algorithmes convertissent automatiquement des schémas logiques en schémas conceptuels Approches expertes tentent de "pousser plus loin" l'automatisation en définissant des heuristiques 5. Conclusion : Les types d'approches

55 139 J. AKOKA &I.WATTIAU Plus de 50 articles sur la rétro-conception de bases de données Un grand nombre de règles dont : –certaines résultent de l'inversion des règles de passage de ER en relationnel et sont contenues dans toutes les approches –d'autres consistent en l'utilisation d'heuristiques et sont plus spécifiques à certaines méthodologies L'enjeu est d'offrir des AGL incluant une fonction intelligente de rétro-conception 5. Conclusion


Télécharger ppt "85 J. AKOKA &I.WATTIAU Conceptualisation : illustration PERSON (ssn, name, address) EMPLOYEE(ssn, name, salary, hired-date) MANAGER(ssn, rank, promotion-date,"

Présentations similaires


Annonces Google