Modélisation de Base de Données dans UML

Introduction

Lorsqu’il vient à fournir fiable, flexible et efficace la persistance d’objet pour systèmes logiciels, les designers et les architectes d’aujourd’hui sont confrontés à beaucoup de choix. Du point de vue technologique, le choix est d’habitude entre, hybrides objet-relationnel, des solutions relationnelles et personnalisés purs Object-Oriented pures basées sur des formats ouverts ou propriétaires fichiers (par ex. XML, OLE stockage structuré). De l’aspect de vendeur Oracle, IBM, Microsoft, POET et d’autres offrent des solutions similaires mais souvent incompatibles.

Cet article est de seulement un de ces choix, qui est la superposition d’un modèle de classe orientée objet au-dessus d’une base de données purement relationnelle. Ceci ne doit pas impliquer que ceci est la solution seule, la meilleure ou la plus simple, mais pragmatique, il est l’un des plus commun, et celui qui a le potentiel pour la plupart mauvais usage.

Nous allons commencer par un tour rapide des deux domaines de conception que nous essayons de pont: tout d’abord le modèle de classe orientée objet ainsi que représenté en UML, et d’autre part le modèle de base de données relationnelle.

Pour chaque domaine nous regardons seulement les fonctions principales qui affecteront notre tâche. Nous examinerons ensuite les techniques et les questions liées à la cartographie à partir du modèle de classe pour le modèle de base de données, y compris la persistance des objets, le comportement de l’objet, les relations entre les objets et l’identité de l’objet. Nous conclurons avec une revue du profil UML données (tel que proposé par Rational Software).
Une certaine familiarité avec le design orientée objet, UML et la modélisation de base de données relationnelle est assumé.

Le modèle de classe dans l’UML est l’artefact principal produit pour représenter la structure logique d’un système logiciel. Il capture le tant exigences de données et le comportement des objets à l’intérieur du domaine du modèle. Les techniques pour découvrir et élaborer ce modèle sont en dehors du champ d’application de cet article, donc nous assumerons l’existence d’un modèle de classe bien conçu qui exige la cartographie sur une base de données relationnelle.

Le Modèle de Classe

La classe est l’entité logique de base dans l’UML. Il définit à la fois les données et le comportement d’une unité de construction. Une classe est un gabarit ou un modèle à partir duquel les instances ou les objets sont créés au moment de l’exécution. Lorsque nous développons un modèle logique comme une hiérarchie structurelle en UML nous traitons explicitement avec des classes. Lorsque nous travaillons avec des diagrammes dynamiques, tels que les diagrammes de séquence et de collaborations, nous travaillons avec des objets ou des instances de classes et de leurs inter-actions au temps d’exécution. Le principal de dissimulation de données ou d’encapsulation est basé sur la localisation d’effet. Une classe a des éléments de données internes qu’il est responsable. L’accès à ces éléments de données devrait être par le comportement ou l’interface exposée de la classe. L’adhésion à cette principaux résultats dans le code plus maintenable.

Comportement

Le comportement est capturé dans le modèle de classe en utilisant les opérations qui sont définies pour la classe. Les opérations peuvent être visibles de l’extérieur (public), visible pour les enfants (protégées) ou cachée (privé). En combinant les données cachées avec une interface accessible au public et la manipulation de données caché ou protégé, un concepteur de la classe peut créer des unités structurelles fortement maintenables qui supportent plutôt que freinent le changement.

Relations et Identité

Association est une relation entre deux classes indiquant qu’au moins un côté de la relation connaît et en quelque sorte utilise ou manipule l’autre côté. Cette relation peut par fonctionnelle (faire quelque chose pour moi) ou structurelles (être quelque chose pour moi). Pour cet article,c’est la relation structurelle qui est la plus intéressante: par exemple une classe d’Adresses peut être associé à une classe de Personne. La cartographie de cette relation dans l’espace de données relationnelle exige une certaine prudence.

Agrégation est une forme d’association qui implique la collecte d’une classe d’objets dans une autre. La composition est une forme plus forte de l’agrégation qui implique un objet est en fait composé des autres. Comme la relation d’association, ce qui implique un attribut de classe complexe qui exige un examen attentif dans le processus de cartographie au domaine relationnel. Alors qu’une classe représente le gabarit ou le modèle à partir duquel de nombreuses instances d’objets peuvent être créés, un objet au moment de l’exécution nécessite certains moyens d’identifier lui-même de telle sorte qui s’est associé les objets peuvent agir sur l’instance d’objet correct. Dans un langage de programmation comme C++, les pointeurs d’objets peuvent être passés autour et maintenus pour permettre objets accès à une instance d’objet unique. Souvent cependant, un objet sera détruit et exigera qu’il soit recréé comme il était lors de sa dernière instance active. Ces objets exigent qu’un mécanisme de stockage sauve leur état interne et associations dans et récupèrent cet état comme exigé.

Héritage fournit le modèle de classe avec un moyen d’affacturage du comportement commun en classes généralisées qui agissent alors comme les ancêtres de beaucoup de variations sur un thème commun. L’héritage est un moyen de gérer à la fois la réutilisation et de la complexité. Comme nous verrons, le modèle relationnel n’a pas de contrepartie directe de l’héritage, ce qui crée un dilemme pour le modeleur de données dressant la carte d’un modèle d’objet sur un cadre relationnel. La Navigation d’un objet au moment de l’exécution à l’autre est basé sur des références absolues. Un objet a une certaine forme de lien (un pointeur ou ID d’objet unique) avec laquelle localiser ou re-créer l’objet exigé.

Le Modèle Relationnel

Le modèle de données relationnelle a été autour depuis de nombreuses années et a l’expérience éprouvée de fournir des prestation et de la flexibilité. Il est essentiellement définie en fonction et a comme unité fondamentale de la ’tableau’, qui est composé d’un ensemble d’un ou plusieurs ’colonnes’, dont chacun contient un élément de données.

Tables et colonnes: une table relationnelle est la collection d’une ou plusieurs colonnes dont chacune a un nom unique dans la construction de table. Chaque colonne est définie comme étant d’un certain type de données de base, par exemple un numéro, un texte ou des données binaires. Une définition de la table est un gabarit à partir duquel les lignes de table sont créés, chaque ligne étant une instance d’une instance de table possible. Le modèle relationnel offre seulement un modèle d’accès aux données publiques. Toutes les données sont également exposés et ouverte à tout processus de mise à jour, requête ou manipuler. La dissimulation d’informations est inconnue..

Comportement

Le comportement associé à une table est généralement basé sur l’entreprise ou de règles logiques appliqués à cette entité. Les contraintes peuvent être appliquées à des colonnes sous la forme d’exigences d’unicité, les contraintes d’intégrité relationnelles vers d’autres tables/ lignes, les valeurs admissibles et les types de données.
Déclencheurs fournissent un comportement supplémentaire qui peut être associé à une entité. Typiquement, cela est utilisé pour faire respecter l’intégrité des données avant ou après les mises à jour, insère et supprime. Les procédures stockée de base de données fournissent un moyen d’étendre les fonctionnalités de base de données par les extensions du langue propriétaire utilisé pour construire des unités fonctionnelles (scripts). Ces procédures fonctionnelles ne correspondent pas directement à des entités, ni avoir une relation logique pour eux. La Navigation par des ensembles de données relationnels est basée sur la rangée. SQL est la langue principale utilisée pour sélectionner les lignes et de localiser les cas d’un ensemble de table.

Relations et Identité

La primary key d’une table fournit la valeur d’identification unique pour une rangée particulière. Il y a deux sortes de "primary key" par laquelle nous sommes intéressés : tout d’abord la clé significative, composée des colonnes de données qui ont une signification dans le domaine d’affaires et la seconde l’identifiant unique abstrait, comme une valeur inverse, qui n’a aucune signification d’affaire, mais identifie uniquement une rangée. Nous allons discuter de cela et les implications de clés significatives plus tard. Une table peut contenir des colonnes qui qui correspondent à la clé principale d’une autre table. Cette relation entre des tables définit une "foreign key" et implique une relation structurelle ou une association entre les deux tables.

Résumé

De la liste ci-dessus, nous pouvons voir que le modèle objet repose sur des entités distinctes ayant à la fois l’état (attributs / données) et le comportement, avec un accès aux données encapsulées généralement via l’interface publique de la classe seulement. Le modèle relationnel expose toutes les données de manière égale, avec un soutien limité pour associer le comportement avec des éléments de données par le biais de triggers, index et les contraintes. Vous naviguez à l’information distincte dans le modèle d’objet en déplaçant d’un objet à l’aide d’identificateurs d’objets uniques et les relations d’objet établies (semblable à un modèle de données de réseau). Dans le modèle relationnel vous trouvez rangées par assemblage et des jeux de résultats de filtrage utilisant SQL en utilisant des critères de recherche généralisées. L’identité dans le modèle d’objet est référence de temps d’exécution ou un ID unique persistant (appelé un OID). Dans le monde relationnel, des clés principales définissent le caractère unique d’un ensemble dans l’espace de données globale des données.

Dans le modèle d’objet, nous avons un riche ensemble de relations: Héritage, Agrégation, Association, Composition, Dépendance et d’autres. Dans le modèle relationnel, nous pouvons réellement spécifier une relation à l’aide des clés étrangères. Après avoir examiné les deux domaines d’intérêt et comparé certaines des caractéristiques importantes de chacun, nous allons une brève digression pour regarder la notation proposé de représenter des modèles de données relationnelles dans l’UML.

Le Profil Modèle de Données d’UML

Le Profil Modèle de Données est une extension de UML pour supporter le modelage de bases de données relationnelles dans UML. Il inclut des extensions personnalisées pour des choses comme les tablesaux, schéma de base de données, les clés de la tableau, les déclencheurs et les contraintes. Bien que ce soit pas une extension ratifié, il illustre encore une technique possible pour modéliser une base de données relationnelle dans l’UML

Tableaux et Colonnes

Un tableau dans le Profil de Données UML est une classe avec le stéréotype "Table", affiché comme ci-dessus avec une icône de la table dans le coin supérieur droit. Colonnes de base de données sont modélisées comme les attributs de la classe de "Table".

Par exemple, la figure ci-dessus montre quelques attributs associés à la table du client. Dans l’exemple, un identifiant de l’objet a été défini comme la primary key, ainsi que deux autres colonnes, Nom et Adresse. Notez que l’exemple ci-dessus définit le type de colonne en fonction des types de données de DBMS natifs.

Comportement

Jusqu’à présent, nous avons seulement définit le structure (statique) de la table logique; En outre, nous devrions décrire le comportement associé à colonnes, y compris les index, les clés, les détentes, les procédures et etc. Le comportement est représenté comme des opérations stéréotypées.

La figure ci-dessous montre notre tableau ci-dessus avec une contrainte de clé principale et de l’indice, à la fois défini comme opérations stéréotypées:

Notez que le drapeau de PK sur la colonne ’OID’ définit la primary key logique, alors que l’opération stéréotypée "PK idx_customer00" définit les contraintes et les comportements associés à la mise en oeuvre de primary key (c’est-à-dire, le comportement de la primary key).

Ajout à notre exemple, nous pouvons maintenant définir des comportements supplémentaires comme des déclencheurs, des contraintes et procédures stockées comme dans l’exemple ci-dessous:

L’exemple illustre le comportement possible après:

1. Une contrainte de Primary key (PK);
2. Une contrainte de Foreign key (FK);
3. Une contrainte d’indice (Index);
4. Un déclencheur (Trigger);
5. Une contrainte d’unicité (Unique);
6. Contrôle de validité (Check).

En utilisant la notation indiquée ci-dessus, il est possible de modéliser les structures de données complexes et le comportement au niveau DBMS. En plus de cela, l’UML fournit la notation d’exprimer les relations entre les entités logiques.

Relations

Le profil UML relations de modélisation des données définit une relation comme une dépendance d’aucune sorte entre deux tableaux. Il est représenté par une association stéréotypée et inclut un ensemble de clés principales et étrangères. Le profil de données continue à exiger qu’une relation implique toujours un parent et l’enfant, le parent définir une clé principale et l’enfant mise en ouvre d’une clé étrangère sur la base de tout ou partie de la clé parent principale. La relation est appelé «identification» si la clé étrangère de l’enfant comprend tous les éléments de la clé principale parent et «non-identification» si seulement certains éléments de la clé principale sont inclus. La relation peut inclure des contraintes de cardinalité et être modélisé avec le PK pertinente - FK paire nommé rôles d’association. L’illustration ci-dessous illustre ce type de modélisation de la relation avec UML.

Le Modèle Physique

UML fournit également des mécanismes pour représenter la structure physique générale de la base de données, son contenu et l’emplacement déployé. Pour représenter une base de données physique dans UML, utiliser un composant stéréotypés comme dans la figure ci-dessous:

Un composant représente une entité discrète et déployable dans le modèle. Dans le modèle physique, un composant peut être mappé sur un morceau de matériel physique (un 'noeud' en UML). Pour représenter le schéma dans la base de données, utilisez le "schéma" stéréotype sur un paquetage. Une tableau peut être placé dans un "schéma" pour établir la portée et la localisation dans une base de données.

Traduisez du Modèle de Classe au Modèle Relationnel

Après avoir décrit les deux domaines d’intérêt et la notation à utiliser, nous pouvons maintenant tourner notre attention sur la façon de la carte ou de traduire d’un domaine à l’autre. La stratégie et la séquence présentée ci-dessous est destiné à être suggestive plutôt que prescriptive - adapter les étapes et les procédures à vos exigences personnels et de l’environnement.

1. Classes Modèles

Tout d’abord, nous allons supposer que nous réalisons un nouveau schéma de base de données relationnel d’un modèle de classe que nous avons créé. C’est évidemment la direction la plus facile comme les modèles restent dans notre contrôle et nous pouvons optimiser le modèle de données relationnel au modèle de classe. Dans le monde réel il peut être que vous avez besoin à la couche d’un modèle de classe en plus d’un modèle de données d’héritage - une situation plus difficile et un celui qui présente ses propres défis. Pour la discussion actuelle se concentrera sur la première situation. Au minimum, votre modèle de classe doit capturer des associations, l’héritage et l’agrégation entre des éléments.

2. Identifier des objets persistants

Ayant construit notre modèle de classe, nous devons séparer en ces éléments qui exigent la persistance et ceux qui ne le font pas. Par exemple, si nous avons conçu notre application en utilisant le motif de conception du Modèle-Vue-Contrôleur, alors seules les classes de la section du modèle, il faudrait un state persistant.

3. Assumez chaques cartes de classe persistantes à une table relationnelle

Une assez grande supposition, mais celui qui fonctionne dans la plupart des cas (en laissant la question de l’héritage de côté pourl’instant). Dans le modèle le plus simple d’une classe à partir du modèle logique mappe à une table relationnelle, en tout ou en partie. Le prolongement logique de ce qui est un objet unique (ou instance d’une classe) mappe à une seule ligne de la table.

4. Choisissez une stratégie d’héritage

L’héritage est peut-être la relation la plus problématique et construction logique du modèle orienté objet qui exige la traduction dans le modèle relationnel. L’espace relationnel est essentiellement plat, chaque entité étant complète dans son soi, tandis que le modèle de l’objet est souvent assez profond avec une hiérarchie de classes bien développé. Le modèle de classe profonde peut avoir plusieurs couches d’attributs et les comportements hérités, résultant en finale un objet entièrement riche en fonctionnalités au temps d’exécution. Il ya trois façons de base pour gérer la traduction de l’héritage d’un modèle relationnel:

1. Chaque hiérarchie de classe a une seule tableau correspondante qui contient tous les attributs hérités de tous les éléments - ce tableau est donc l’union de toutes les classes dans la hiérarchie. Par exemple, Personne, Parent, Enfant et Petit-enfant peuvent tous former une seule hiérarchie de classes, et les éléments de chaque apparaîtront dans la même tableau relationnelle;
2. Chaque classe dans la hiérarchie correspond a une tableau des seuls attributs accessibles par cette classe (incluant des attributs hérités). Par exemple, si l’Enfant est hérité de Personne seulement, donc le tableau contiendra les éléments de la Personne et des Enfants seulement;
3. Chaque génération dans la hiérarchie de classe a une tableau contenant uniquement des attributs réels de cette génération. Par exemple, l’enfant va dériver d’une simple tableau avec l’enfant attribue seulement

Il ya des cas à faire pour chaque approche, mais je suggérerais la plus simple, plus facile à maintenir et à moins d’erreurs est la troisième option. La première option offre les meilleures performances lors de l’exécution et le second est un compromis entre le premier et le dernier. La première option aplatit la hiérarchie et localise tous les attributs d’une table - pratique pour les mises à jour et les récupérations de toute classe dans la hiérarchie, mais difficiles à authentifier et à maintenir. Les règles de gestion associées à une rangée sont difficiles à mettre en ouvre, comme chaque rangée peut être instancié comme un objet dans la hiérarchie. Les dépendances entre les colonnes peuvent devenir très compliqué. En outre, une mise à jour à une classe dans la hiérarchie va avoir une incidence sur toutes les autres classes dans la hiérarchie, comme des colonnes sont ajoutées, supprimées ou modifiées de la tableau.

La deuxième option est un compromis qui fournit une meilleure encapsulation et élimine les colonnes vides. Cependant, un changement à une classe parent peut avoir besoin d’être reproduit dans de nombreux tableaux de l’enfant. Encore pire, les données parentales dans deux ou plusieurs classes d’enfants peuvent être redondante stockés dans plusieurs tableaux; si les attributs d’un parent sont modifiées, il ya des efforts considérables dans la localisation des enfants à charge et mettre à jour les lignes affectées.

La troisième option reflète plus fidèlement le modèle d’objet, à chaque classe dans la hiérarchie mappée vers sa propre table indépendante. Mises à jour pour les parents ou les enfants sont localisées dans l’espace correct. La maintenance est aussi relativement facile, car toute modification d’une entité est limité à une seule table relationnelle aussi. L’inconvénient est la nécessité de reconstruire la hiérarchie au temps de l’exécution de précision recréer l’état d’une classe enfant. Un objet de l’enfant peut exiger une variable membre personne pour représenter leur parentage modèle. Comme les deux nécessitent le chargement, deux appels de base de données sont nécessaires pour initialiser un objet. Comme la hiérarchie élargit, avec plus de générations, le numbre d’appels nécessaires pour initialiser ou mettre à jour un seul objet augmente base de données.

Il est important de comprendre les questions qui se posent lorsque vous mappez héritage sur un modèle relationnel, donc vous pouvez vous décider que la solution est juste pour vous.

5. Pour chaque classe ajouter un identificateur d’objet unique

Dans les deux relationnel et le monde de l’objet, il ya la nécessité d’identifier de manière unique un objet ou entité. Dans le modèle d’objet, les objets non persistants au moment de l’exécution sont généralement identifiés par référence directe ou par un pointeur à l’objet. Une fois qu’un objet est créé, nous pouvons nous y référer par son identité de temps d’exécution. Cependant, si nous écrivons un objet au stockage, le problème est de savoir comment récupérer la même instance exacte sur demande. La méthode la plus pratique consiste à définir un OID (identificateur d’objet) qui est garanti pour être unique dans l’espace de noms d’intérêt. Ceci peut être à la classe, le paquetage ou le niveau de système, selon des exigences réelles.

Un exemple d’un système se nivelle OID pourrait être un GUID (Globally Unique Identifier) créé avec ’GUIDGen’ l’outil de Microsoft; par exemple. {A1A68E8E-CD92-420b-BDA7-118F847B71EB}. Un OID de niveau de classe peut être implémentée en utilisant un simple numérique (par ex. 32 de compteur de bits). Si un objet contient des références à d’autres objets, il peut le faire en utilisant leur OID. Un scénario complet d’exécution peut alors être chargé à partir de stockage raisonnablement efficace. Un point important sur les valeurs OID ci-dessus est qu’ils ont pas de signification intrinsèque delà de l’identité simple. Ils ne sont que des pointeurs logiques et rien de plus. Dans le modèle relationnel, la situation est souvent tout à fait différente.

Identité dans le modèle relationnel est normalement mis en ouvre avec une clé primaire. Une clé primaire est un ensemble de colonnes dans un tableau qui, ensemble, identifier de manière unique une rangée. Par exemple, le nom et l’adresse peuvent identifier de façon unique un «client». Là où d’autres entités, comme un «Vendeur», référence au «Client», ils mettent en ouvre une clé étrangère sur la base de la clé primaire ’client’. Le problème avec cette approche pour nos fins est l’impact d’avoir des informations de l’entreprise (comme le nom et l’adresse du client) noyé dans l’identifiant. Imaginez trois ou quatre tableaux ont toutes les clés étrangèr es sur la base de la clé primaire de la clientèle, et un changement de système nécessite la clé primaire de la clientèle à changer (par exemple pour inclure «le type de client»). Le travail exigé pour modifier tant la tableau ’client’ que les entités liées par la clé étrangère est tout à fait grand.

D’autre part, si un OID a été mis en ouvre en tant que la clé primaire et la clé étrangère formée pour d’autres tableaux, la portée de la modification est limitée à la tableau primaire et l’impact de la modification est donc beaucoup moins. En outre, dans la pratique, une clé primaire sur la base de données de l’entreprise peut être sujet à changement. Par exemple, un client peut changer l’adresse ou le nom. Dans ce cas, les modifications doivent être propagées correctement à toutes les autres entités apparentées, sans parler de la difficulté de changer les informations qui fait partie de la clé primaire.

Un OID se réfère toujours à la même entité - peu importe ce que d’autres modifications de l’information. Dans l’exemple ci-dessus, un client peut changer de nom ou d’adresse et les tables liées ne nécessitent pas de changement. Lors du mappage des modèles d’objets dans des tableaux relationnelles, il est souvent plus pratique de mettre en ouvre l’identité absolue à l’aide plutôt que les clés primaires de business liées à des OID. L’OID comme approche clé primaire et étrangère sera généralement donner de meilleurs charge et de mise à jour de fois pour des objets et de minimiser l’effort de maintenance. En pratique, une clé primaire de business liées pourrait être remplacé par:

• Une contrainte d’unicité ou un index sur les colonnes concernées;
• Les règles de gestion intégrés dans le comportement de la classe;
• Une combinaison de 1 et 2.

Encore, la décision d’utiliser les touches significatives ou OID dépendra des conditions exactes du système en cours d’élaboration.

6. Organiser des attributs de colonnes

En général, nous allons correspondre les attributs de données simples d’une classe à colonnes dans la tableau relationnelle. Par exemple, un champ de texte et le nombre peut représenter respectivement le nom et l’âge d’une personne. Cette sorte de cartographie directe devrait pas poser de problème - il suffit de sélectionner le type de données approprié en modèle relationnel du fournisseur pour héberger votre attribut de classe.

Pour les attributs complexes (ie. Les attributs qui sont d’autres objets) utiliser l’approche détaillée ci-dessous pour les associations de manutention et l’agrégation.

7. Plan associations à clés étrangères

Les attributs de classe plus complexes (ie. Ceux qui représentent d’autres classes), sont généralement modélisés comme des associations. Une association est une relation structurelle entre les objets. Par exemple, une personne peut vivre à une adresse. Bien que cela puisse être modélisée comme une personne a la ville, la rue et les attributs postaux, à la fois l’objet et le monde relationnelle nous sommes enclins à structurer cette information comme une entité séparée, une adresse. Dans le domaine de l’objet une adresse représente un objet physique unique, éventuellement avec un OID unique. Dans le relationnel, une adresse peut être une ligne dans une tableau d’adresses, avec d’autres entités ayant une clé étrangère à la Adresse clé primaire.

Dans les deux modèles alors, il ya la tendance à déplacer les informations d’adresse dans une entité séparée. Cela permet d’éviter les données redondantes et améliore la maintenabilité. Donc, pour chaque association dans le modèle de classe, envisager la création d’une clé étrangère de l’enfant à la table parentale.

8. Plan d’Agrégation et Composition

Agrégation et composition relations sont similaires à la relation d’association et correspondent aux tableaux liées par paires clé primaire-étrangère. Il ya cependant quelques points à garder à l’esprit. Agrégation ordinaire (la forme faible) modèles relations telles que réside une personne à une ou plusieurs adresses. Dans ce cas, plus d’une personne pourrait vivre à la même adresse, et si la personne a cessé d’exister, les adresses associées avec eux serait encore exister. Cet exemple est parallèle à la ’plusieurs à plusieurs’ relation dans la terminologie relationnelle, et est généralement mis en ouvre dans un tableau distinct contenant une cartographie des clés primaires d’une tableau à l’aide des touches primaires d’une autre.

Un deuxième exemple de la forme faible de l’agrégation est quand une entité possède utilisation ou la propriété exclusive d’un autre. Par exemple, une entité de personne regroupe un ensemble d’actions. Cela implique une personne peut être associé à zéro ou plusieurs actions à partir d’une tableau de partager, mais chaque action peut être associé à zéro ou une personne. Si la personne cesse d’exister, les actions deviennent non détenues ou sont passés à une autre personne. Dans le monde relationnel, cela pourrait être mis en ouvre chaque action ayant une colonne ’propriétaire’ qui stocke un ID de personne (ou OID).

La forte forme d’agrégation, cependant, a des contraintes d’intégrité importantes qui lui sont associés. Composition, implique que l’entité est composé de parties, et les parties ont une relation de dépendance à l’ensemble. Par exemple, une personne peut avoir des documents d’identification tel qu’un passeport, certificat de naissance, permis de conduire & etc. Une entité Person peut être composée de l’ensemble de ces documents d’identification. Si la personne est supprimé du système, les documents d’identification doivent être supprimées aussi, comme ils sont liés à un individu unique.

Si nous ignorons la question OID pour le moment, une agrégation faible pourrait être implémentée en utilisant soit une table intermédiaire (pour le cas de ’plusieurs à plusieurs’) ou avec une clé étrangère dans la classe agrégée tableau (-un à plusieurs cas) . Dans le cas de la relation ’plusieurs à plusieurs’, si le parent est supprimé, les entrées de la tableau intermédiaire pour cette entité doivent également être supprimées également. Dans le cas de la relation ’un à plusieurs’, si le parent est supprimé, l’entrée de clé étrangère (ie. ’Propriétaire’) doit être effacé.

Dans le cas de la composition, l’utilisation d’une clé étrangère est obligatoire, avec la contrainte supplémentaire que sur la suppression de la mère de la partie doit être également supprimé. Logiquement il ya aussi l’implication avec la composition que la clé primaire de la partie forme une partie de la clé primaire de l’ensemble - par exemple, la clé primaire d’une personne peut composé de leurs documents d’identification ID de. En pratique, cela serait lourd, mais la relation logique qui est vraie.

9. Définir les rôles de relation

Pour chaque relation de type d’association, chaque fin de la relation peuvent être précisés avec les informations de rôle. Typiquement vous inclurez le nom de contrainte de clé primaire et le nom Contrainte de clé étrangère. La figure 6 illustre ce concept. Ceci définit la relation logique entre les deux classes. De plus, vous pouvez spécifier des contraintes supplémentaires (par ex. {Non NULL}) sur le rôle et la cardinalité contraintes (par exemple. 0..N).

10. Comportement de Modèle

Nous arrivons maintenant à une autre question difficile: si le comportement de planifier tout ou classe pour les capacités fonctionnelles fournies par les fournisseurs de bases de données sous forme de triggers, procédures stockées, l’unicité et les contraintes de données, et l’intégrité relationnelle. Un modèle d’objet non persistant serait typiquement mettre en ouvre tous les comportements exigé dans un ou plusieurs langages de programmation (par exemple. Java ou C ++). Chaque classe sera donnée à son comportement exigé et responsabilités en forme du public, protégée et des méthodes privées.

Bases de données relationnelles de différents fournisseurs comprennent généralement une certaine forme de programmable SQL langage de script basé à mettre en ouvre la manipulation de données. Les deux exemples les plus courants sont les déclencheurs et les procédures stockées. Quand nous mélangeons l’objet et modèles relationnels, la décision est généralement si de mettre en ouvre toute la logique de business dans le modèle de classe, ou pour déplacer les uns pour les déclencheurs souvent plus efficaces et des procédures stockées mises en ouvre dans les DBMS relationnels. D’un point de vue purement orientée objet, la réponse est évidemment d’éviter les déclencheurs et les procédures stockées et placez tous les comportements dans les classes. Cette localise comportement, prévoit un design plus propre, simplifie la maintenance et offre une bonne portabilité entre les vendeurs de DBMS.

Dans le monde réel, le résultat final peut être mise à l’échelle à 100 ou de 1000 de transactions par seconde, et les procédures stockées et les déclencheurs sont conçus pour cela. Si la pureté du design, de la portabilité, la maintenance et la flexibilité sont les principaux facteurs, localiser tous les comportements dans les méthodes de l’objet.

Si la performance est une préoccupation primordiale, envisager de déléguer certains comportements des plus efficaces langues DBMS de script. Sachez cependant que le temps supplémentaire pris pour intégrer le modèle d’objet avec les procédures stockées d’une façon sûre, y compris les questions ayant des effets éloignés et le débogage, peut coûter plus cher en temps de développement que de déployer simplement pour du matériel plus capable.

Comme mentionné plus tôt, le Profil de Données UML fournit les extensions suivantes (opérations stéréotypées) avec lequel vous pouvez modeler le comportement DBMS:

• Contrainte de Primary key (PK)
• Contrainte de Foreign key (FK)
• Contrainte de Index (Index)
• Déclencher (Trigger)
• Déclencher (Unique)
• Contrôle de validité (Check)

11. Produire un modèle physique

Dans UML, le modèle physique décrit comment quelque chose sera déployé dans le monde réel - la plate-forme matérielle, la connectivité réseau, logiciels, système d’exploitation, dll et d’autres composants. Vous produisez un modèle physique pour compléter le cycle - d’un cas ou le domaine de l’utilisation modèle initial, à travers le modèle de classe et des modèles de données et enfin le modèle de déploiement. Typiquement, pour ce modèle, vous allez créer un ou plusieurs nouds qui hébergent la base de données et placer les composants logiciels de DBMS sur eux. Si la base de données est répartie sur plus d’une instance DBMS, vous pouvez attribuer des paquetages ("schéma") des tableaux à un seul composant DBMS pour indiquer où les données seront résider.

Conclusion
Ceci conclut ce article court sur la modélisation de base de données en utilisant le langage UML. Comme vous pouvez le voir, il ya quelques questions tout à fait à prendre en considération lors de la planification du monde de l’objet à l’relationnelle. L’UML fournit un soutien pour combler le fossé entre les deux domaines, et en collaboration avec des extensions comme le Profil de Données UML est un bon langage pour intégrer avec succès les deux mondes.