Relations et Power Pivot - mannequins

Vous n'avez pas besoin d'être un modeleur de base de données expert pour utiliser Power Pivot. Mais il est important de comprendre les relations. Mieux vous comprendrez comment les données sont stockées et gérées dans les bases de données, plus Power Pivot sera efficace pour générer des rapports.

Une relation est le mécanisme par lequel des tables distinctes sont liées entre elles. Vous pouvez considérer une relation comme un VLOOKUP, dans lequel vous reliez les données d'une plage de données aux données d'une autre plage de données à l'aide d'un index ou d'un identifiant unique. Dans les bases de données, les relations font la même chose, mais sans les tracas d'écrire des formules.

Les relations sont importantes car la plupart des données avec lesquelles vous travaillez s'intègrent dans une sorte de hiérarchie multidimensionnelle. Par exemple, vous pouvez avoir un tableau montrant les clients qui achètent des produits. Ces clients ont besoin de factures portant des numéros de facture. Ces factures ont plusieurs lignes de transactions énumérant ce qu'ils ont acheté. Une hiérarchie existe là.

Maintenant, dans le monde de la feuille de calcul à une dimension, ces données sont généralement stockées dans une table plate, comme celle présentée ici.

Les données sont stockées dans une feuille de calcul Excel à l'aide d'un format de table à plat.

Les clients ayant plusieurs factures, les informations client (dans cet exemple, CustomerID et CustomerName) doivent être répétées. Cela provoque un problème lorsque ces données doivent être mises à jour.

Imaginons, par exemple, que le nom de la société Aaron Fitz Electrical soit remplacé par Fitz and Sons Electrical. En regardant la table, vous voyez que plusieurs lignes contiennent l'ancien nom. Vous devez vous assurer que chaque ligne contenant le nom de l'ancienne société est mise à jour pour refléter le changement. Toutes les lignes que vous ratez ne seront pas redirigées correctement vers le bon client.

Ne serait-il pas plus logique et efficace d'enregistrer le nom et l'information du client une seule fois? Ensuite, plutôt que d'avoir à écrire les mêmes informations client à plusieurs reprises, vous pouvez simplement avoir une certaine forme de numéro de référence client.

C'est l'idée derrière les relations. Vous pouvez séparer les clients des factures, en les plaçant dans leurs propres tables. Vous pouvez ensuite utiliser un identifiant unique (tel que CustomerID) pour les relier entre eux.

La figure suivante illustre l'aspect de ces données dans une base de données relationnelle. Les données seraient divisées en trois tables distinctes: Customers, InvoiceHeader et InvoiceDetails. Chaque table serait alors liée en utilisant des identifiants uniques (CustomerID et InvoiceNumber, dans ce cas).

Les bases de données utilisent des relations pour stocker des données dans des tables uniques et relient simplement ces tables entre elles.

La table Customers contiendrait un enregistrement unique pour chaque client. De cette façon, si vous avez besoin de changer le nom d'un client, vous devez effectuer la modification uniquement dans cet enregistrement. Bien sûr, dans la vie réelle, la table Customers inclurait d'autres attributs, tels que l'adresse du client, le numéro de téléphone du client et la date de début du client. Tous ces autres attributs peuvent également être facilement stockés et gérés dans la table Customers.

Le type de relation le plus courant est une relation un-à-plusieurs. En d'autres termes, pour chaque enregistrement d'une table, un enregistrement peut être associé à plusieurs enregistrements dans une table distincte. Par exemple, une table d'en-tête de facture est liée à une table de détail de facture. La table d'en-tête de facture a un identifiant unique: Numéro de facture. Le détail de la facture utilisera le numéro de facture pour chaque enregistrement représentant un détail de cette facture particulière.

Un autre type de relation est la relation one-to-one: pour chaque enregistrement d'une table, un et un seul enregistrement correspondant se trouve dans une table différente. Les données de différentes tables dans une relation un-à-un peuvent techniquement être combinées dans une seule table.

Enfin, dans une relation plusieurs-à-plusieurs, les enregistrements des deux tables peuvent contenir n'importe quel nombre d'enregistrements correspondants dans l'autre table. Par exemple, une banque de données peut avoir une table des différents types de prêts (prêt immobilier, prêt automobile, etc.) et un tableau des clients. Un client peut avoir plusieurs types de prêts. Pendant ce temps, chaque type de prêt peut être accordé à de nombreux clients.