Developpement:Modèle et langage -2
Modification dans le modèle métier.
Nouveaux types de données.
Type de données « Entier long » et « Chaîne Unicode »
| Entier long | 64 bits signés | bigint | numeric(20,0) |
| Chaîne unicode | Chaîne de longueur variable | nvarchar() | nvarchar2() |
Ces types ont été introduits pour faciliter le support de classe SQL mappé sur des tables relationnelles utilisant ces types, il n’est pas conseillé de les utiliser dans des classes métiers car ils n’apportent aucun avantage sauf si vous avez réellement besoin de manipuler des entiers 64 bits.
Le support des « chaînes Unicode » est limité aux entrées sorties avec la base de données ; en fait une données de type chaine Unicode est équivalente à une données de type chaîne. La seule différence est dans le type de données SQL utilisé pour stocker le contenu dans la base de données. Notamment les chaînes Unicode ne sont pas supportées dans l’interface utilisateur ni dans les requêtes.
Type de données XML
Le type de données XML permet de gérer des documents ou des fragments XML. Les attributs techniques disponibles sur un type de données XML sont :
| AsString | Contenu du document sous forme chaîne de caractère. |
| AsVariant | Equivalent à AsString |
| Document | Document XML de type TxmlDocument |
Le code métier peut utiliser l’attribut technique « Document » pour manipuler le contenu du document :
Type
SQLORA_MaClasseXML = Class(TdbObject)
public
oid: string;
Caption: string;
data: TxmlDocumentDataType;
unCode: string;
Procedure MethodName;
end;
Implementation
{SQLORA_MaClasseXML}
Procedure SQLORA_MaClasseXML.MethodName;
//Procedure MethodName;
var idx:Integer; itm:TxmlItem;
begin
for idx:=0 to data.Document.Count-1 do
begin
itm := data.Document.Items[idx];
showMessage(itm.ItemName);
end;
end;
Stockage des types XML
Le stockage des types XML se fait dans des colonnes typées XML si ce type est disponible sur le moteur de base de données, ceci peut avoir les conséquences suivantes :
Le moteur peut vérifier la validité du contenu du champ, une erreur SQL peut être déclenchée si le contenu xml n’est pas valide.
Le moteur peut reformater le contenu du champ, par exemple SQLServer normalise le contenu texte en supprimant les nœuds textes ne contenant que des blancs (au sens xml ce qui inclus les retours chariot et les retours à la ligne).
| Moteur de base de données | Stockage |
| SQL Server 2005 | Colonne de type XML |
| SQL Server 2000 | Colonne mémo |
| Sage SQL et Oracle | Colonne mémo |
Type de données XSL
Le type de données XSL est un descendant du type de données XML ; il permet de gérer des feuilles de style XSL.
Les attributs techniques disponibles sur un type de données XML sont :
| Document | Document XSL de type TxslDocument |
Exemple d’utilisation des attributs XML.
Cet exemple utilise une classe contenant un attribut XML et un attribut XSL pour construire un contenu HTML. Il utilise le nouveau contrôle TSyntaxEdtor pour afficher les documents XML.
La classe utilisée :
unit TestSQLORA
interface
Type
SQLORA_MaClasseXML = Class(TdbObject)
private
textResult: TMemoDataType;
public
Caption: string;
unCode: string;
xmlData: TxmlDocumentDataType;
xslData: TxslDocumentDataType;
Procedure Transformer;
end;
Implementation
{SQLORA_MaClasseXML}
Procedure SQLORA_MaClasseXML.Transformer;
//Procedure Transformer;
begin
textResult.AsString := xslData.Document.TransformToString(xmlData.Document);
end;
L’attribut textResult est une variable dont le contenu est créé par la méthode « Transformer » ; celle-ci utilise la méthode TransformToString du document XSL de l’attribut xslData.
La vue des données XML :
La vue de la feuille de style
Après exécution de la méthode de transformation, la vue du résultat HTML :
|
Il existe une méthode plus directe pour afficher le résultat en utilisant le nouveau contrôle ThtmlDIV orienté XML ; voir le document sur l’Interface utilisateur pour un exemple. |
Modèle relationnel des classes persistantes
Préfixes de classe.
Auparavant les classes métiers devaient être préfixées avec « T » et les interfaces avec « I », cette limitation a été supprimée. Toutefois le dialogue de création de classe impose toujours l’utilisation de ces préfixes pour ces stéréotypes de classe.
Nom des table SQL
Auparavant le nom des tables SQL étaient systématiquement en majuscule, cette limitation a été supprimée. Toutefois lors de la création de classe persistante le nom SQL par défaut est en majuscule.
Stéréotype de paquet
Les paquets peuvent être stéréotypés suivant le contenu du paquet. Les stéréotypes définis sont :
Les paquets de classes métiers
Ce sont les paquets contenant du métier ligne 1000.
Les paquets de classes datamart.
Ce sont les paquets contenant des classes datamart destinés à alimenter des info-centres.
Lors de la création d’un paquet vous pouvez sélectionner le stéréotype adéquat.
Classes et procédures de service et procédures distantes
Les procédures de service sont contenues dans des classes services locales et sont publiable en Web Service.
Les procédures distantes sont contenues dans des classes de services distants et sont appelables à travers l’invocation de Web Service.
Voir le document consacré au Web Service.
Classes sql et classes datamart.
Une classe SQL est une classe mappée sur une table relationnelle SQL. Une classe SQL utilise la clé primaire de la table SQL pour identifier une instance d’objet, un tuple en SQL, à la place des identifiants d’objets (oid). Les classes SQL ne sont pas « objets » et ne permettent pas d’utiliser les fonctionnalités du framework liées à la méthodologie objet, comme par exemple l’héritage de classe.
Une classe Datamart est une classe SQL utilisée dans le contexte d’opération ETL. Elle ajoute la notion d’agrégats utilisés dans les systèmes décisionnels.
Importation de modèle relationnel
L’assistant d’importation de modèle relationnel permet de créer un modèle objet à partir d’un modèle relationnel existant. Le modèle peut utiliser soit des classes objets persistantes soit des classes SQL.
En général un modèle basé sur des classes objets ne permettra pas de fonctionner sur des données existantes mais pourra être enrichi de fonctionnalités objets alors qu’un modèle basée sur des classes SQL fonctionnera sur des données existantes mais ne pourra pas utiliser les fonctionnalités objets.
Les limitations
Les classes SQL ne peuvent gérer que des clés primaires mono-colonne.
Les rôles des classes SQL ne peuvent gérer que des clés étrangères mono-colonne.
Les rôles utilisables sont les références et les listes.
La concurrence d’accès ne peut être que « super optimiste » ; les modes « optimistes » (basé sur les timestamp) et pessimiste (basé sur des verrous sur les oid) ne peuvent pas fonctionner.
Les types de données du framework, basés sur des objets et stockés dans la base de données sur des structures SQL complexes, ne peuvent pas être utilisés.
Seul un sous ensemble des types de données SQL est utilisable
Les types de données
La ligne 1000 ne gère qu’un sous ensemble des types de données SQL existants, il est donc possible que certain types de données des tables SQL ne soient pas supportés. Dans ce cas l’assistant propose le type de données supporté le plus approprié. Lorsqu’aucun type n’est proposable la colonne est marqué à ignorer.
Les types de données nativement supportés sont :
| Type | SQL Server | Oracle |
| Chaîne | varchar | CHAR, VARCHAR2 |
| OID | TOID | CHAR(32) |
| Entier (32 bits) | int | NUMBER(10,0) |
| Flottant (15 chiffres, 8 octets) | float | NUMBER, FLOAT |
| Monétaire (8 octets) | money | NUMBER(20,4) |
| Date et heure | datetime | DATE |
| Logique | int | NUMBER(10,0) |
| Texte | text | CLOB |
| Binaire | image | BLOB |
L’assistant d’importation de modèle relationnel.
Pour importer un modèle relationnel contenu dans une base de données :
Enregistrer la base de données dans l’administrateur, cela exécutera les scripts lignes 1000 permettant au framework 1000 de fonctionner. Ceci ne modifie en aucune façon les tables existantes.
Créer une nouvelle application contenant le module système et un module métier vide. Associer le module métier à la base de données.
Créer une nouvelle société utilisant cette application et cette société.
Entrez dans la société, ouvrez le concepteur de modèle et sur la racine des paquets appelez l’assistant d’importation de modèle relationnel.
L’assistant d’importation créera un paquet métier que vous associerez à votre module métier.
Vous sélectionnez d’abord le type d’importation :
Le comportement de la génération dépend du mode choisi :
Importation en classes orientées SQL
L’ensemble des colonnes sera intégrés, excepté celles exclues par l’utilisateur.
Importation en classes persistantes
Les colonnes primaires ne seront pas intégrées puisqu’elles sont remplacées par le mécanisme basé sur les oids.
L’assistant présente ensuite les tables existantes dans la base de données :
Seule les tables pour lesquelles il n’existe pas de classe sont présentées ; après sélection des tables souhaités une vue en modèle est présentée :
Sur cette vue vous pouvez contrôler certain éléments de la génération :
Sur une classe :
Vous pouvez modifier le nom de la classe qui sera importé, notez que le nom de table ne peut pas être modifié.
Lorsque vous importez une table en classe SQL il est possible que vous ne souhaitiez pas synchroniser le modèle de données, par exemple si certaines colonnes sont exclues ou importer avec un type non natif.
Sur une colonne :
Indique que le type de donnée de la colonne est nativement supporté. Lorsque le type de données n’est pas natif l’assistant propose un type de données le plus approprié, cependant il est possible que des limitations en découle ; par exemple un type bigint (64 bits) sera proposé en int (32 bits) mais il est clair que l’étendu du type sera limité
Ces cases à cochés vous renseigne sur l’usage de la colonne.
Vous pouvez modifier le type de données qui sera affecté à la colonne ; il est déconseillé de modifier ce type pour les colonnes dont le type est nativement supporté.
Vous pouvez décider de ne pas importer une colonne ; les colonnes dont les types de données ne sont pas supportés et ne peuvent pas être reconnus sont exclus par défaut. C’est, par exemple, le cas avec SQL 2005 qui présente des colonnes dont le type de données n’est pas présent dans la table systypes des types.
Sur un rôle :
Par défaut l’assistant crée un rôle liste réciproque pour chaque référence (c'est-à-dire pour chaque clé étrangère).
L’assistant crée systématiquement un paquet pour un import, vous devez donc renseigner les informations de paquet. Notez que vous pouvez ajouter un préfix de paquet.
Que vous associez ensuite à un module de votre application :
Avant de générer le paquet :
Modèle de datamart
Les modèles de datamart sont des paquets contenant des classes datamart destinées à alimenter des infocentres. Le but des modèles de datamart est donc de présenter vos données métiers suivant des vues facilement exploitables par les outils décisionnels ; en général ces modèles sont fortement dé-normalisés afin d’obtenir les performances désirées lors de l’exécution des requêtes décisionnelles.
La démarche pour créer un nouvel infocentre est la suivante :
Créer une nouvelle base de données pilotée dans l’administrateur; cette base sera votre infocentre.
Créer un module vide et associé le à la base infocentre.
Ajouter cette base infocentre à votre société.
Entrez dans votre société, dans le concepteur de modèle ajouter un paquet et sélectionné le stéréotype « Paquet de classes datamart » ; associé le au module associé à la base infocentre.
Vous pouvez maintenant ajouter des classes datamart à votre paquet.
L’intérêt des classes datamart est que vous pouvez créer des requêtes ETL pour alimenter ces classes. Une requête ETL est une requête, réalisée avec l’outil de construction de requête, capable d’être exécuter en insertion, modification ou suppression. Un requête ETL est construite à partir d’une classe métier et alimente une classe datamart. Vous pouvez ensuite regrouper ces requêtes dans des groupes de requête ETL et insérer ces groupes dans des tâche ETL de l’automate afin d’automatiser la mise à jour de votre infocentre.
Notez que les fonctionnalités liées au datamart et aux requêtes ETL ne sont pas lié à un système décisionnel particulier. Toutefois les bases de données pilotées ont un type particulier dans l’administrateur car elles peuvent être associées à des serveurs et des univers « Business Objects ».
| Whos here now: Members 0 Guests 0 Bots & Crawlers 1 |
