Introduction à la conception de base de données
Cet article / tutoriel vous apprendra la base de la conception de base de données relationnelle et explique comment faire une bonne base de données. Il est un texte assez long, mais nous conseillons de lire tout cela. La conception d'une base de données est en fait assez facile, mais il y a quelques règles à respecter. Il est important de savoir quelles sont ces règles, mais plus important encore est de savoir pourquoi ces règles existent, sinon vous aurez tendance à faire des erreurs!
La normalisation rend votre modèle de données flexible et qui permet de travailler avec vos données beaucoup plus facile. S'il vous plaît, prenez le temps d'apprendre ces règles et de les appliquer! La base de données utilisée dans cet article est conçu avec notre outil de conception et de modélisation base de données pour les bases de données DeZign.
Une bonne base de données commence par une liste des données que vous souhaitez inclure dans votre base de données et ce que vous voulez être en mesure de le faire avec la base de données plus tard. Tout cela peut être écrit dans votre propre langue, sans SQL. Dans ce stade, vous devez essayer de ne pas penser à des tables ou des colonnes, mais il suffit de penser: « Que dois-je savoir » Ne prenez pas ce trop à la légère, parce que si vous trouvez plus tard que vous avez oublié quelque chose, en général, vous devez tout recommencer. Ajout de choses à votre base de données est la plupart du temps beaucoup de travail.
entités identification
Les types d'informations qui sont enregistrées dans la base de données sont appelées « entités ». Ces entités existent en quatre types: les gens, les choses, les événements et les lieux. Tout ce que vous voulez mettre dans une base de données entre dans l'une de ces catégories. Si les informations que vous souhaitez inclure ne rentre pas dans ces catégories, qu'elle ne l'est probablement pas une entité mais une propriété d'une entité, un attribut.
Mais ce que d'autres choses se produisent lors de la vente d'un produit? Un client entre dans le magasin, approche du vendeur, pose une question et obtient une réponse. « Les vendeurs » participent également, et parce que les vendeurs sont des gens, nous avons besoin d'une entité de fournisseurs.
identification des relations
L'étape suivante consiste à déterminer les relations entre les entités et de déterminer la cardinalité de chaque relation. La relation est la connexion entre les entités, tout comme dans le monde réel: qu'est-ce une entité voir avec l'autre, comment ils se rapportent les uns aux autres? Par exemple, les clients achètent des produits, les produits sont vendus aux clients, une vente comprend des produits, une vente se produit dans un magasin.
La cardinalité montre combien d'un côté de la relation appartient à quel point de l'autre côté de la relation. Tout d'abord, vous devez indiquer pour chaque relation, combien d'un côté appartient à exactement 1 de l'autre côté. Par exemple: Combien de clients appartiennent à 1 vente ?; Combien appartiennent les ventes à 1 client ?; Combien de ventes ont lieu dans 1 magasin?
Vous obtiendrez une liste comme ceci: (s'il vous plaît noter que « produit » représente un type de produit, pas un occurance d'un produit)
- Les clients -> Ventes; 1 client peut acheter quelque chose plusieurs fois
- Ventes -> Clients; 1 vente est toujours faite par 1 client au moment
- Les clients -> Produits; 1 client peut acheter plusieurs produits
- Produits -> Clients; 1 produit peut être acheté par plusieurs clients
- Les clients -> Boutiques; 1 client peut acheter dans plusieurs magasins
- Boutiques -> Clients, 1 boutique peuvent recevoir plusieurs clients
- Boutiques -> Produits; dans 1 boutique il y a plusieurs produits
- Produits -> Magasins; 1 produit (type) peut être vendu dans plusieurs magasins
- Boutiques -> Ventes; dans 1 boutique plusieurs ventes peuvent me faire
- Ventes -> Magasins; 1 vente ne peut être faite dans 1 boutique au moment
- Produits -> Ventes; 1 produit (type) peut être acheté dans plusieurs ventes
- Ventes -> Produits; 1 vente peut exister sur plusieurs produits
Avons-nous mentionné toutes les relations? Il y a quatre entités et chaque entité a une relation avec chaque autre entité, de sorte que chaque entité doit avoir trois relations, et apparaissent également sur l'extrémité gauche de la relation à trois reprises. Au-dessus, 12 relations ont été mentionnées, ce qui est 4 * 3, donc nous pouvons conclure que toutes les relations ont été mentionnées.
Maintenant, nous allons mettre les données ensemble pour trouver la cardinalité de la relation ensemble. Pour ce faire, nous rédigerons les cardinalités par rapport. Pour que cela soit facile à faire, nous allons ajuster la notation un peu, en notant la « relation-backward' l'inverse:
- Les clients -> Ventes; 1 client peut acheter quelque chose plusieurs fois
- Ventes -> Clients; 1 vente est toujours faite par 1 client au moment
La deuxième relation que nous tournera autour de sorte qu'il a le même ordre d'entité que le premier. S'il vous plaît noter la flèche qui est maintenant face à l'autre façon!
- Les ventes Clients; 1 client peut acheter quelque chose plusieurs fois; 1: N.
- Les ventes Clients; -> 1: N
- Les clients -> Produits; -> M: N
- Les clients -> Boutiques; -> M: N
- Ventes -> Produits; -> M: N
- Boutiques -> Ventes; -> 1: N
- Boutiques -> Produits; -> M: N
Les relations ventes -> Clients et ventes -> Produits sont obligatoires, mais l'inverse ce n'est pas le cas. Un client peut exister sans la vente, et aussi un produit peut exister sans la vente. Ceci est d'une importance pour l'étape suivante.
Les relations récursives
Parfois, une entité se réfère à lui-même. Par exemple, pensez à une hiérarchie de travail: un employé a un patron; et le bosschef est un employé aussi. L'attribut « patron » de l'entité « employés » renvoie à « employés » l'entité.
Dans un ERD (voir chapitre suivant) ce type de relation est une ligne qui sort de l'entité et revient avec une belle boucle à la même entité.
Les relations redondantes
Parfois, dans votre modèle, vous obtiendrez une « relation redondante ». Ce sont des relations qui sont déjà signalées par d'autres relations, mais pas directement.
Dans le cas de notre exemple, il existe une relation directe entre les clients et les produits. Mais il y a aussi des relations des clients à des ventes et des ventes aux produits, donc il est déjà indirectement une relation entre les clients et les produits grâce à la vente. Les relations « clients Produits » est faite deux fois, et l'un d'entre eux est donc superflu. Dans ce cas, les produits ne sont achetés par une vente, de sorte que les relations des clients Produits »peuvent être supprimés. Le modèle ressemblera alors à ceci:
Résolution de nombreux à-plusieurs
Beaucoup à de nombreuses relations (M: N) ne sont pas directement possible dans une base de données. Quel M: relation N dit est qu'un nombre d'enregistrements d'une table appartient à un certain nombre d'enregistrements d'une autre table. Quelque part vous devez enregistrer qui enregistre ce sont la solution est de diviser la relation en deux un à plusieurs.
Cela peut se faire en créant une nouvelle entité qui est entre les entités liées. Dans notre exemple, il y a un grand nombre à plusieurs entre les ventes et les produits. Ceci peut être résolu en créant une nouvelle entité: sous-produits de vente. Cette entité a beaucoup à une relation avec les ventes, et un grand nombre à une relation avec les produits. Dans les modèles logiques on appelle cela une entité associative et en termes de base de données physique ce qu'on appelle une table de lien ou d'une table de jonction.
Dans l'exemple, il y a deux beaucoup à de nombreuses relations qui doivent être résolus: « Produits de vente » et « Produits Magasins ». Pour les deux cas il faut créer une nouvelle entité, mais quelle est cette entité?
Pour les produits de vente relation, chaque vente comprend plus de produits. La relation montre le contenu de la vente. En d'autres termes, il donne des détails sur la vente. Ainsi, l'entité est appelée « les détails de vente ». Vous pouvez nommer aussi « produits vendus ».
La relation magasins Produits montre quels produits sont disponibles dans les magasins où, également connu sous le nom « stock ». Notre modèle ressemblerait maintenant à ceci:
Attributs pour l'identification
Les éléments de données que vous souhaitez enregistrer pour chaque entité sont appelés « attributs ».
A propos des produits que vous vendez, vous voulez savoir, par exemple, ce que le prix est, ce que le nom du fabricant est, et ce que le numéro de type est. A propos des clients que vous connaissez leur numéro de client, leur nom et adresse. A propos des magasins que vous connaissez le code de localisation, le nom, l'adresse. Parmi les ventes que vous savez quand ils se sont produits, dans quel magasin, quels produits ont été vendus, et la somme totale de la vente. Sur le vendeur vous connaissez son numéro personnel, le nom et l'adresse. Ce qui sera inclus est précisément pas d'une importance encore; il est encore que sur ce que vous voulez enregistrer.
Les données dérivées
données dérivées sont des données qui est dérivé des autres données que vous avez déjà enregistrées. Dans ce cas, la « somme totale » est un cas classique de données dérivées. Vous savez exactement ce qui a été vendu et que le coût de chaque produit, de sorte que vous pouvez toujours calculer combien la somme totale des ventes est. Alors, vraiment il ne faut pas pour sauver la somme totale.
Alors, pourquoi est-il sauvé ici? Eh bien, parce qu'il est une vente et le prix du produit peut varier au fil du temps. Un produit peut être au prix de 10 euros aujourd'hui et à 8 euros le mois prochain, et pour votre administration vous devez savoir ce qu'il en coûte au moment de la vente, et la meilleure façon de le faire est de l'enregistrer ici. Il y a beaucoup de façons plus élégantes, mais ils sont trop profonds pour cet article.
Présenter les entités et les relations: diagramme entité-relation (ERD)
L'entité Diagramme des relations (ERD) donne un aperçu graphique de la base de données. Il existe plusieurs styles et types de diagrammes ER. Une notation très utilisée est la notation « crowfeet », où les entités sont représentées par des rectangles et les relations entre les entités sont représentées sous forme de lignes entre les entités. Les signes à la fin des lignes indiquent le type de relation. Du côté de la relation qui est obligatoire pour l'autre d'exister sera indiqué par un tableau de bord sur la ligne. Non entités obligatoires sont indiqués par un cercle. « Beaucoup » est indiqué par un « crowfeet »; de relation en ligne se divise en trois lignes.
Dans cet article, nous utilisons des bases de données pour DeZign de concevoir et de présenter notre base de données.
Une relation 1: 1 obligatoire est représentée comme suit:
A 1: N relation obligatoire:
Touches Affectation
Les clés étrangères
Si nous mettons tous les liens entités, PK et FK de l'ERD dans, nous obtenons le modèle comme illustré ci-dessous. S'il vous plaît noter que l'attribut « produits » ne sont plus nécessaires dans les « ventes », parce que « les produits vendus » est maintenant inclus dans le lien table. Dans le lien table un autre champ a été ajouté, la « quantité », qui indique le nombre de produits ont été vendus. Le champ de la quantité a également été ajoutée dans le stock-table, pour indiquer combien de produits sont encore en magasin.
Définir le type de données de l'attribut
Maintenant, il est temps de déterminer quels types de données doivent être utilisés pour les attributs. Il y a beaucoup de différents types de données. Quelques sont standardisés, mais de nombreuses bases de données ont leurs propres types de données qui ont tous leurs propres avantages. Certaines bases de données OffreLe possibilité de définir vos propres types de données, dans le cas où les types standards ne peuvent pas faire les choses dont vous avez besoin.
Les types de données standard que chaque base de données connaît, et sont les plus utilisés sont les suivants: CHAR, VARCHAR, TEXT, FLOAT, DOUBLE et INT.
Texte:- CHAR (longueur) - comprend le texte (caractères, chiffres, ponctuations.). CHAR a pour caractéristique qu'il enregistre toujours une quantité fixe de positions. Si vous définissez un CHAR (10), vous pouvez économiser jusqu'à dix positions au maximum, mais si vous utilisez seulement deux positions la base de données encore enregistrer 10 positions. Les huit postes seront comblés par des espaces.
- VARCHAR (longueur) - comprend le texte (caractères, chiffres, signes de ponctuation.). VARCHAR est le même que CHAR, la différence est que VARCHAR ne prend autant d'espace que nécessaire.
- TEXT - peut contenir de grandes quantités de texte. En fonction du type de base de données, cela peut ajouter jusqu'à giga-octets.
- INT - contient un nombre entier positif ou négatif. Beaucoup de bases de données ont des variations de l'INT, comme TINYINT, SMALLINT, MEDIUMINT, BIGINT, INT2, INT4, INT8. Ces variations diffèrent de l'INT uniquement dans la taille de la figure qui correspond en elle. Une INT régulière est de 4 octets (int4) et correspond à des chiffres -2147483647 à 2147483646, ou si vous définissez comme UNSIGNED de 0 à 4294967296. Le INT8 ou BIGINT, peut être encore plus grand en taille, 0-18446744073709551616, mais prend jusqu'à 8 octets d'espace disque, même s'il y a juste un petit nombre en elle.
- FLOAT, DOUBLE - La même idée que INT, mais peut également stocker nombres à virgule flottante. Prenez note que cela ne fonctionne pas toujours parfaitement. Par exemple, dans le calcul MySQL avec ces nombres à virgule flottante n'est pas parfait, (1/3) * 3 donnera aux flotteurs de MySQL à 0,9999999, pas 1.
- Blob - pour les données binaires telles que files.INET - pour les adresses IP. Aussi utilisable pour netmasks.
Pour notre exemple, les types de données sont les suivantes:
Normalisation
Rend votre modèle Normalization de données flexible et fiable. Il ne génère certains frais généraux parce que vous obtenez habituellement plusieurs tables, mais il vous permet de faire beaucoup de choses avec votre modèle de données sans avoir à régler.
La normalisation, la première forme
Quel est le problème à ce sujet est que maintenant seulement 3 produits peuvent être vendus. Si vous devez vendre 4 produits, que vous devez commencer une deuxième vente ou d'ajuster votre modèle de données en ajoutant « produit4 » attributs. Les deux solutions sont indésirables. Dans ces cas, vous devez toujours créer une nouvelle entité que vous créez un lien vers l'ancien par un à plusieurs.
Normalization, la deuxième forme
Cette entité n'est pas selon la deuxième forme de normalisation, parce que, pour être en mesure de rechercher la date d'une vente, je n'ai pas savoir ce qui est vendu (productnr), la seule chose que je dois savoir est le nombre de ventes. Cela a été résolu en divisant les tables dans les ventes et la table Sales_details:
Maintenant, chaque attribut des entités dépend de l'ensemble PK de l'entité. La date dépend du nombre de ventes, et la quantité dépend du nombre de ventes et le produit vendu.
La normalisation, la troisième forme
Dans ce cas, le prix d'un produit en vrac dépend du numéro de commande et le numéro de commande dépend du numéro de produit et le nombre de ventes. Cela ne veut pas selon la troisième forme de normalisation. Encore une fois, le fractionnement des tables résout ce.
Plus, les formes de normalisation
Il y a plus de formes de normalisation que les trois formes mentionnées ci-dessus, mais ce ne sont pas d'un grand intérêt pour l'utilisateur moyen. Ces autres formes sont hautement spécialisés pour certaines applications. Si vous vous en tenez aux règles de conception et la normalisation mentionnés dans cet article, vous allez créer un design qui fonctionne très bien pour la plupart des applications.
Normalisé Modèle de données
Si vous appliquez les règles de normalisation, vous constaterez que le « fabricant » dans le tableau de produit devrait également être une table séparée:
Attributs - des données détaillées sur une entité, comme le prix, la longueur, le nom
Cardinalité - la relation entre les deux entités, en chiffres. Par exemple, une personne peut passer plusieurs commandes.
Entités - données abstraites que vous enregistrez dans une base de données. Par exemple: les clients, les produits.
Normalisation - Un modèle de données flexible doit respecter certaines règles. L'application de ces règles est appelé normalisant.
Apprendre- DeZign pour les bases de données. En savoir plus sur DeZign pour les bases de données.
- Mise en route avec DeZign pour les bases de données. Commencez à faire un modèle de données directement.
- types de données d'affichage dans un diagramme. Apprenez à afficher le type de données et / ou des informations de domaine dans les zones d'entités sur votre diagramme.
- Construisez votre prochain modèle de données avec DeZign pour les logiciels de bases de données d'essai, disponible en téléchargement directement à partir de la section de téléchargement de Datanamic.