Corriger les défauts de conception de la table Employee

possibilité RDA Logical Data Model (LDM) pour refaçonner ce changement, comme le montre la figure 2.

La table Employee_Bio ne contient que les colonnes jugées non sensibles ou non volatiles. Les colonnes de données sensibles et volatiles ont été transférées dans la table Employee_Pay. La volatilité peut être un facteur majeur quand des changements sont effectués sur des tables qui sont journalisées (journalisées en utilisant DB2 i). En essence, si des lignes entières d’images sont journalisées, les données sensibles sont journalisées quand le numéro de téléphone de l’employé change. Ou bien toute l’image biographique est journalisée quand l’information de paie change. En outre, des index de performance supportant des fonctions agrégées (par exemple, MIN, MAX) sur des colonnes de paie, doivent être maintenus lorsqu’on insère de nouveaux employés ou supprime des employés inactifs. Ce point est important dans les divisions fabrication et détail d’ACME, où l’emploi est saisonnier et la rotation du personnel importante.

ACME a adopté les règles suivantes pour toutes les tables nouvelles ou soumises à réingénierie :
• Chaque table parente doit avoir une clé primaire ou unique
• Chaque table doit avoir un tampon horodateur de changement de ligne
• Ces nouvelles colonnes doivent être autogénérées
• Ces colonnes doivent être cachées aux yeux de l’application

Pour satisfaire à ces exigences, le DBE a créé une nouvelle colonne (EMP_ID) définie comme LONG dans le LDM (cela sera transformé en un BIGINT pour DB2 i). En outre, elle est désignée comme la Primary Key (contrainte de clé primaire) et surrogate (AS IDENTITY) et les valeurs sont dérivées (autogénérées) en utilisant des valeurs par défaut, comme le montre la figure 3.

Les colonnes de tampon horodateur de changement de ligne sont ajoutées dans le cadre de la conception LDM. Les possibilités de tampon horodateur d’autogénération et 6.1 IMPLICITLY HIDDEN seront ajoutées dans le cadre du déploiement PDM.

Le champ EMP_ID est utilisé pour créer une relation entre les tables Employee_Bio et Employee_Pay. En essence, EMP_ID devient une clé étrangère. Bien que EMPNO soit actuellement utilisé dans les relations existantes, il est considéré par ACME comme sensible et par conséquent ne peut pas se propager aux travers des tables. Le champ EMP_ID sera utilisé pour établir des relations de clé primaire-étrangère à partir de ce point.

La cardinalité entre Employee_Bio et Employee_Pay est désignée en tant que zéro ou un. Cela signifie qu’un enregistrement Employee_Bio peut exister sans un enregistrement Employee_Pay. Autre avantage pour ACME : la société peut produire une liste des employés actifs sur la paye (ceux qui ont un enregistrement de paie) en joignant les tables Bio et Pay à l’aide de la colonne EMP_ID. Cela dispense d’un flag « status » dans les tables des employés désignant actif ou inactif. (Je reviens plus en détail sur l’alternative du flag status dans la section « Utiliser des déclencheurs INSTEAD OF »). La figure 4 montre les propriétés des relations.

Une fois que le modèle LDM est bouclé, passé en revue et approuvé, le DBE transforme le LDM en un PDM basé sur la cible RDBMS (DB2 i dans le cas présent). Rien n’est plus simple. Premièrement, choisir Transform, Physical Data Model dans la barre de menus RDA. Deuxièmement, sélectionner Create new model dans la fenêtre Transform To Physical Data Model. Troisièmement, choisir la base de données cible (DB2 i), cliquer sur Next et prendre les défauts sur tous les écrans restants.

Avant de déployer les nouvelles tables, le DBE règle finement quelques aspects du script DDL généré. En essence, la version actuelle de RDA utilisée par le DBE ACME ne supporte pas la nouvelle clause 6.1 IMPLICITLY HIDDEN ou les possibilités de tampon horodateur de changement de ligne autogénérées. Le DBE passera outre cette limitation en utilisant l’option Data, Generate DDL de la barre de menus PDM, puis en modifiant le script DDL à l’aide de Snippets.

En essence, les Snippets vous permettent de créer des modèles de code réutilisables que vous pouvez insérer dans le code source existant. En outre, les modèles peuvent contenir des variables de remplacement, permettant de personnaliser (si nécessaire) le code inséré pour chaque usage.