On m'a remis un immense fichier plat de données sur les demandes d'assurance-maladie. Il contient 1,3 million de lignes et 154 colonnes. Je dois faire un tas d'analyses différentes sur ces données. Ce sera dans SQL Server 2012.Dois-je normaliser un fichier plat d'enregistrement de 1,3 million pour l'analyse?
Le fichier a 25 colonnes pour les codes de diagnostic (DIAG_CD01 par DIAG_CD_25), 8 pour les codes de facturation (ICD_CD1 par ICD_CD8), et 4 pour les codes de modification de la procédure (MODR_CD1 par MODR_CD4). On dirait qu'il a été jeté à partir d'une base de données relationnelle. Les codes de facturation et de diagnostic serviront de base à une grande partie de l'analyse. Donc, ma question est de savoir si je devrais diviser le fichier dans une base de données relationnelle factice. Écrire des requêtes d'analyse sur une table comme celle-ci sera un cauchemar. Si je le divise en une table parent et trois tables enfants (Diagnoses, Modifiers et Bill_codes), mon code de requête sera beaucoup plus facile. Mais si je fais cela, j'aurais, en plus des 1,3 million de dossiers de parents, jusqu'à 32,5 millions de dossiers de diagnostic, jusqu'à 10,4 millions de dossiers de codes de facturation, et jusqu'à 5,2 millions de dossiers de modificateurs. D'un autre côté, une grande partie des données plates des trois ensembles sont des champs nuls, qui sont supposés nuire aux performances des requêtes. Quelles sont les conséquences probables sur les performances de l'interrogation de ces données en tant que base de données relationnelle fictive par rapport au fichier plat géant? En lisant à propos de la normalisation, il semble que les performances devraient être meilleures, mais le nombre d'enregistrements dans une division de quatre tables me donne une pause.
Les données dénormalisées sont beaucoup plus faciles à analyser. La normalisation est utilisée pour éviter les anomalies de mise à jour mais il semble que ces données soient statiques –
AFAIK dénormalisé est plus facile à vivre. Et si les performances sont importantes, ne le faites pas en SQL. Si vous chargez les données dans la RAM locale et écrivez votre code en langage C ou dans un langage de programmation «classique», vous pouvez utiliser diverses structures de données avancées et atteindre une vitesse inégalée. –
@NeilMcGuigan Oui, c'est statique. Je voudrais éviter les requêtes avec 24 'ou' lignes si – Rominus