> Tech > Valeurs NULL et types de données

Valeurs NULL et types de données

Tech - Par iTPro - Publié le 24 juin 2010
email

Un modèle de données contribue à garantir la validation intelligente des données de deux manières.

Premièrement, il peut vous aider à décider si un attribut est nécessaire. Si c’est le cas, vous pouvez forcer le schéma à rejeter les valeurs NULL en définissant l’attribut à NOT NULL. De

Valeurs NULL et types de données

même, il est possible d’améliorer la validation des données en employant des types de données avec contraintes, lesquels forcent les données à demeurer dans une plage de valeurs définie. Par exemple, au lieu d’utiliser un type integer pour représenter une valeur à deux ou trois états (par exemple, « null », « yes », « no »), envisagez d’employer un bit car, par définition, il autorisera au maximum trois valeurs possible : 1, 0 et NULL. Prenons un autre exemple : SQL Server représente toutes les valeurs de date comme date + heure au moyen du type datetime. Dans les situations pour lesquelles vous devez garantir que les utilisateurs accèdent à des valeurs uniquement de type date, vous pouvez exposer une date normalisée, arrondie à 12:00 A.M., en utilisant des colonnes calculées au lieu de demander aux utilisateurs de se souvenir que chaque requête référençant la valeur de date doive inclure manuellement également l’heure. Les attributs opening_date et opening_ datetime dans la table Account illustrent cette technique, comme le bloc A du listing 2 le montre. L’utilisation de colonnes calculées vous permet de capturer le moment précis d’ouverture d’un compte (avec l’heure de la journée), tout en exposant une version avec contrainte de la valeur en question, opening_date, qui permet aux utilisateurs d’écrire des requêtes simples sans avoir à se soucier d’exclure par inadvertance des comptes qui n’ont pas été ouverts dans les limites précises du jour en question.

Parfois, même avec des données valides, vous pouvez utiliser de petits changements du modèle de données afin d’accroître la cohérence et la précision des rapports. Cette stratégie met l’accent sur l’intégration d’une « version unique de la vérité » dans vos modèles de données en déportant les calculs complexes utilisés fréquemment du code du rapport vers un état persistant dans le modèle de données. L’exploitation d’une « version unique de la vérité » est le plus souvent associée à des solutions d’analyse décisionnelle telles que les entrepôts de données (data warehouse) et data marts.

Néanmoins, cette technique est également applicable sur les systèmes transactionnels qui utilisent des calculs tels que la dérivation de l’âge à partir d’une date de naissance ou un calcul plus complexe tel que les actifs nets moyens du trimestre en cours au sein d’un système financier. L’application de cette technique a souvent un coût élevé en raison du coût accru sur les performances de la préservation de la valeur calculée. Toutefois, le fait d’éviter la frustration occasionnée par plusieurs personnes aboutissant à un résultat différent pour un calcul sur le même ensemble de valeurs compense souvent largement les effets supplémentaires au niveau performances.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 24 juin 2010