Modélisation des données 101
Table des matières
1. Qu'est-ce que la modélisation des données?
La modélisation des données est le fait d'explorer des structures orientées données. Tout comme les autres artefacts de modélisation des modèles de données peuvent être utilisés pour des fins diverses, à partir de modèles conceptuels de haut niveau pour les modèles de données physiques. Du point de vue d'une modélisation des données de développement orienté objet est conceptuellement similaire à la modélisation de classe. Avec la modélisation des données vous identifier les types d'entité alors que la modélisation des classes que vous identifiez les classes. attributs de données sont affectés à des types d'entités comme vous assigner des attributs et des opérations à des classes. Il existe des associations entre les entités, similaires aux associations entre les classes - les relations, l'héritage, la composition et l'agrégation sont tous les concepts applicables dans la modélisation des données.
la modélisation des données traditionnelles est différente de la modélisation de classe, car il se concentre uniquement sur les données - modèles de classe vous permettent d'explorer à la fois le comportement et les données aspects de votre domaine, avec un modèle de données que vous ne pouvez explorer les questions de données. Pour cette raison modélisateurs de données mise au point ont tendance à être beaucoup mieux à obtenir les données « droit » que modélisateurs objet. Cependant, certaines personnes modèleront méthodes de base de données (procédures stockées, les fonctions stockées et déclencheurs) quand ils sont la modélisation des données physiques. Il dépend de la situation bien sûr, mais je pense personnellement que cela est une bonne idée et promouvoir le concept dans mon profil UML de modélisation des données (voir plus loin).
Bien que l'objectif de cet article est la modélisation des données, il y a souvent des alternatives aux artefacts orientés données (jamais oublier plusieurs modèles de principe Agile Modeling). Par exemple, en ce qui concerne les schémas ORM de modélisation conceptuelle ne sont pas votre seule option - En plus de SGDL il est assez fréquent pour les gens de créer des diagrammes de classes UML et même des cartes de responsabilité Classe Collaboratrice (CRC) à la place. En fait, mon expérience est que les cartes CRC sont supérieurs aux diagrammes ORM car il est très facile d'obtenir des parties prenantes du projet qui participent activement à la création du modèle. Au lieu d'un analyste traditionnel, session de dessin vous dirigée par l au lieu de faciliter pouvez les parties prenantes grâce à la création de cartes CRC.
1.1 Comment les modèles de données utilisés dans la pratique?
Bien que les questions de méthodologie sont couverts par la suite. nous avons besoin de discuter de modèles de données peuvent être utilisées dans la pratique pour mieux les comprendre. Vous êtes susceptible de voir trois styles de base du modèle de données:
- modèles conceptuels de données. Ces modèles, parfois appelés modèles de domaine, sont généralement utilisés pour explorer les concepts de domaine avec les parties prenantes du projet. Sur les équipes agiles modèles conceptuels de haut niveau sont souvent créés dans le cadre de vos exigences initiales Envisioning les efforts qu'ils sont utilisés pour explorer les structures commerciales statiques de haut niveau et des concepts. Sur les équipes traditionnelles modèles conceptuels de données sont souvent créées comme le précurseur de MLD ou alternatives à LDM.
- modèles de données logiques (LDM). LDM sont utilisés pour explorer les concepts de domaine et leurs relations, de votre domaine de problème. Cela pourrait se faire pour le cadre d'un seul projet ou pour toute votre entreprise. LDM représentent les types d'entités logiques, on appelle généralement simplement les types d'entité, les données décrivant les attributs de ces entités et les relations entre les entités. LDM sont rarement utilisés sur les projets agiles sont bien souvent sur des projets traditionnels (où ils semblent rarement ajouter beaucoup de valeur dans la pratique).
- modèles de données physiques (PDMS). PDMs sont utilisés pour concevoir le schéma interne d'une base de données, représentant les tables de données, les colonnes de données de ces tables, et les relations entre les tables. PDMs se révèlent souvent utiles sur les projets agiles et traditionnels et en conséquence l'objet de cet article est sur la modélisation physique.
Figure 1. Un modèle de données logique simple.
Figure 2. Un modèle physique de données simple.
Lorsqu'une base de données relationnelle est utilisée pour les équipes de projet de stockage de données sont mieux conseillé de créer un PDMS pour modéliser son schéma interne. Mon expérience est qu'un PDM est souvent l'un des objets de conception critiques pour des projets de développement d'applications d'entreprise.
2.2. Qu'en est-modèles conceptuels?
2.3. Modélisation des données communes Notations
Figure 4. La comparaison de la syntaxe des notations de modélisation de données communes.
Tableau 1. Discussion notations de modélisation de données communs.
Très bons livres pratiques sur la modélisation des données comprennent des données de Joe Celko - Bases de données et de la modélisation des données pour les professionnels de l'information qu'ils mettent l'accent à la fois sur des questions pratiques avec la modélisation des données. Le Manuel de modélisation des données et modèle de données Les modèles sont les deux excellentes ressources une fois que vous avez maîtrisé les fondamentaux. Introduction aux systèmes de base de données est un bon traité académique pour tous ceux qui souhaitent devenir un spécialiste des données.
3.1 Identifier les types d'entités
Un type d'entité, aussi appelé simplement entité (pas exactement la terminologie exacte, mais très courante dans la pratique), est similaire sur le plan conceptuel au concept de l'orientation objet d'une classe - un type d'entité représente une collection d'objets similaires. Un type d'entité pourrait représenter une collection de personnes, des lieux, des choses, des événements ou des concepts. Exemples d'entités dans un système d'entrée de commande incluraient Client. Adresse. Commande. Article. et l'impôt. Si vous étiez modélisation de classe que vous attendez de découvrir des cours avec les mêmes noms exacts. Cependant, la différence entre une classe et un type d'entité est que les classes ont des données et le comportement alors que les types d'entités ont juste des données.
Idéalement, une entité doit être normal. la version du monde de la modélisation des données de cohésion. Une entité normale représente un concept, comme un modèle de classe cohésifs un concept. Par exemple, le client et l'ordre sont clairement deux concepts différents; donc il est logique de les modéliser comme des entités distinctes.
3.2 Identifier les attributs
Chaque type d'entité aura un ou plusieurs attributs de données. Par exemple, la figure 1 vous avez vu que l'entité client possède des attributs tels que Nom et prénom et la figure 2 que la table tCustomer avait des colonnes de données correspondant CUST_FIRST_NAME et CUST_SURNAME (une colonne est la mise en œuvre d'un attribut de données dans une base de données relationnelle) .
3.3 Appliquer les conventions de nommage de données
Votre organisation devrait établir des normes et des lignes directrices applicables à la modélisation des données, quelque chose que vous devriez être en mesure d'obtenir de vos administrateurs d'entreprise (si elles ne vous devriez pas faire pression existent pour avoir un peu mis en place). Ces lignes directrices devraient inclure les conventions de nommage pour la modélisation à la fois logique et physique, les conventions de nommage logiques devraient être axées sur la lisibilité humaine alors que les conventions de nommage physiques reflètent des considérations techniques. Vous pouvez clairement voir que les différentes conventions de nommage ont été appliquées aux figures 1 et 2.
Comme vous l'avez vu dans Introduction à la modélisation Agile. AM inclut la pratique des normes Appliquer la modélisation. L'idée de base est que les développeurs doivent accepter et suivre un ensemble commun de normes de modélisation sur un projet de logiciel. Tout comme il y a valeur suivant les conventions de codage communes, code propre qui suit vos directives de codage choisi est plus facile à comprendre et à évoluer que le code qui ne fonctionne pas, il y a une valeur similaire à la suite des conventions de modélisation communes.
3.4 Identifier les relations
Dans le monde réel entités ont des relations avec d'autres entités. Par exemple, les clients passer des commandes, clients, LIVE AT adresses et postes sont dans les ordres. Place, vivent à et font partie sont tous les termes qui définissent les relations entre les entités. Les relations entre les entités sont conceptuellement identiques aux relations (associations) entre les objets.
Figure 5. Un modèle logique de données (notation Information Engineering).
Vous devez également identifier la cardinalité et l'optionalité d'une relation (UML combine les concepts de optionalité et cardinalité dans le concept unique de multiplicité). Cardinalité représente le concept de « combien », alors que optionalité représente le concept de « si vous devez avoir quelque chose. » Par exemple, il ne suffit pas de savoir que passer des commandes clients. Combien de commandes peut un lieu de client? Aucun, un, ou plusieurs? En outre, les relations sont les rues à double sens: non seulement passer des commandes des clients, mais les commandes sont passées par les clients. Cela conduit à des questions comme: combien de clients peuvent être inscrits dans un ordre donné et est-il possible d'avoir une commande sans client impliqué? La figure 5 montre que les clients placent zéro ou plusieurs commandes et que tout ordre donné est placé par un client et un seul client. Il montre également qu'un client vit à une ou plusieurs adresses et que toute adresse donnée a zéro clients ou plus à elle.
Bien que l'UML distingue entre les différents types de relations - les associations, l'héritage, l'agrégation, la composition et la dépendance - modélisateurs ne sont souvent pas aussi concernés de données sur cette question, autant que les modélisateurs d'objets sont. Le sous-typage, une application de l'héritage, se trouve souvent dans les modèles de données, dont un exemple est une relation entre l'article et il est deux « entités sous » services et produits. L'agrégation et la composition sont beaucoup moins fréquents et doit généralement être déduit du modèle de données, comme vous le voyez avec la partie du rôle que l'élément de ligne prend la commande. dépendances UML sont généralement une construction logicielle et donc n'apparaissent sur un modèle de données, à moins bien sûr qu'il était un modèle physique très très détaillé qui a montré comment vues, déclencheurs, procédures stockées ou dépendaient d'autres aspects du schéma de base de données.
3.5 Appliquer Patterns Modèle de données
3.6 Clés Assigner
Il existe deux stratégies fondamentales pour l'attribution des clés aux tables. D'abord, vous pouvez attribuer une clé naturelle qui est un ou plusieurs attributs de données existants qui sont uniques au concept d'affaires. Le tableau à la clientèle de la figure 6 il y avait deux candidats clés, dans ce cas CustomerNumber et socialSecurityNumber. En second lieu, vous pouvez introduire une nouvelle colonne, appelée une clé de substitution, ce qui est une clé qui n'a pas de sens de l'entreprise. Un exemple est la colonne AddressID de la table d'adresses dans la figure 6. Les adresses ne dispose pas d'un « facile » clé naturelle parce que vous devez utiliser toutes les colonnes de la table d'adresses pour former une clé pour lui-même (vous pourriez être en mesure de sortir avec juste la combinaison de la rue et ZipCode en fonction de votre domaine de problème), introduit donc une clé de substitution est une option beaucoup mieux dans ce cas.
3.7 Normaliser pour réduire la redondance des données
La figure 7 représente un schéma de base de données dans la FON tandis que la figure 8 représente un schéma normalisé en 3NF. Lire l'introduction à l'essai pour plus de détails Normalisation des données.
Pourquoi la normalisation des données? L'avantage d'avoir un schéma de données hautement normalisé est que les informations sont stockées dans un endroit et un seul endroit, ce qui réduit la possibilité de données incohérentes. De plus, les schémas de données hautement normalisés en général sont plus proches sur le plan conceptuel des schémas orientés objet parce que les objectifs orientés objet de promouvoir une forte cohésion et le couplage lâche entre les classes des résultats dans des solutions similaires (au moins d'un point de vue des données). Cela rend généralement plus facile à la carte vos objets à votre schéma de données. Malheureusement, la normalisation est généralement à un coût de performance. Avec le schéma de données de la figure 7 toutes les données pour une seule commande est stockée dans une rangée (en supposant des commandes jusqu'à neuf points d'ordre), ce qui rend très facile d'accès. Avec le schéma de données de la figure 7, vous pouvez déterminer rapidement le montant total d'une commande en lisant la ligne unique de la table Order0NF. Pour ce faire avec le schéma de données de la figure 8 vous auriez besoin de lire les données à partir d'une ligne dans le tableau de commande, les données de toutes les lignes de la table OrderItem pour cet ordre et les données des lignes correspondantes dans la table d'objet pour chaque élément de commande . Pour cette requête, le schéma de données de la figure 7 fournit très probablement une meilleure performance.
Dans la modélisation de classe, il existe un concept similaire appelé classe bien que ce soit Normalization au-delà de la portée de cet article.
3.8 Dénormaliser pour améliorer les performances
5. évolutionnaire / Agile Modélisation des données
la modélisation des données est évolutive modélisation de données effectué d'une manière itérative et progressive. L'article explore le développement évolutionnaire le développement de logiciels d'évolution plus en détail. la modélisation des données agile est la modélisation de l'évolution des données effectuée d'une manière collaborative. L'article Agile Modélisation des données: de la modélisation de domaine à la modélisation physique fonctionne à travers une étude de cas qui montre comment adopter une approche agile pour la modélisation des données.
6. Comment devenir mieux la modélisation des données
Comment voulez-vous améliorer vos compétences en modélisation de données? Pratique, pratique, pratique. Chaque fois que vous obtenez une chance que vous devriez travailler en étroite collaboration avec Agile CBM, bénévole pour modéliser des données avec eux. et leur poser des questions que l'avancement des travaux. CBM Agile seront en suivant le modèle de la pratique AM avec d'autres utilisateurs devrait donc accueillir l'assistance, ainsi que les questions -. L'une des meilleures façons d'apprendre vraiment votre métier est d'avoir quelqu'un comme « pourquoi tu fais cette façon » Vous devriez être capable d'acquérir des compétences de modélisation des données physiques de compétences de modélisation Agile, et les données DBAs souvent logiques aussi bien.
De même, vous devriez profiter de l'occasion de travailler avec les architectes d'entreprise au sein de votre organisation. Comme vous l'avez vu dans Agile l'architecture d'entreprise, ils devraient prendre un rôle actif sur votre projet, mentorat de votre équipe de projet dans l'architecture d'entreprise (le cas échéant), vous mentorat dans les compétences de modélisation et d'architecture, et d'aider dans les efforts de modélisation et de développement de votre équipe. Encore une fois, volontaire pour travailler avec eux et poser des questions quand vous le faites. architectes d'entreprise seront en mesure de vous enseigner les compétences de modélisation des données conceptuelles et logiques ainsi que instiller une appréciation pour les problèmes de l'entreprise.
Vous devez également faire de la lecture. Bien que cet article est un bon début, il est seulement une brève introduction. La meilleure approche est de simplement demander le CBM Agile que vous travaillez avec ce qu'ils pensent que vous devriez lire.
Partager avec des amis:
Aidons
lecture recommandée
J'ai aussi maintenir une page des livres de base de données agile qui Panoramiques de nombreux livres que vous trouverez intéressant.