Les sections suivantes montrent comment les relations de table de base de données ont été conçues. Les noms d’objets sont fournis afin que vous puissiez facilement les examiner dans la base de données Northwind 2.0 Starter Edition.
Pour ouvrir le diagramme de relation montrant les six tables et les relations entre elles, sélectionnez Outils de base de données > Relations.
Ce diagramme montre les six tables. Dans le diagramme, les lignes entre les tables identifient les relations entre elles. Le 1 et le symbole infini (∞) aux extrémités des lignes représentent le côté un d’une relation (par exemple, un client) et le côté plusieurs d’une relation. Par exemple, un client envoie de nombreuses commandes. Pour plus d’informations, consultez Guide des relations de table.
Les principes suivants s’appliquent aux tables dans Northwind 2.0 Starter Edition, ainsi qu’aux tables en général.
Clés primaires Identifiez de manière unique chaque enregistrement dans une table. Toutes les tables ont une clé primaire. Dans le diagramme de relation, les symboles de clé identifient ces clés primaires. Les conventions de nommage de clé primaire sont nommées pour la table dans laquelle elles se trouvent, par exemple, « TableNameID ».
Efficacité Pour de meilleures performances et un stockage plus efficace, les clés primaires doivent être numériques. En outre, il est plus pratique qu’Access génère automatiquement la nouvelle valeur unique pour la clé primaire de chaque nouvel enregistrement. Le type de données NuméroAuto présente les deux caractéristiques. Les numéros automatiques sont des nombres autrement non significatifs et n’ont aucune autre fonction. Pour plus d’informations, consultez Ajouter un champ NuméroAuto en tant que clé primaire.
Clés étrangères Une table peut également avoir une ou plusieurs clés étrangères, selon qu’elle est liée à d’autres tables de la base de données. Une clé étrangère contient des valeurs qui correspondent aux valeurs de la clé primaire de la table associée.
Index uniques D’autres champs des tables peuvent également avoir leurs propres index uniques, par exemple OrderStatus.StatusCode. Il est illogique d’avoir deux états de commande dans la table OrderStatus avec le même code, même si StatusCode n’est pas lui-même la clé primaire. Un index unique indique à Access d’empêcher les valeurs en double dans ce champ.
Index non uniques Les tables peuvent également avoir des index pour accélérer les recherches et les tris sur ces champs, par exemple Orders.OrderDate. De nombreuses commandes peuvent être passées le même jour, et vous souhaitez souvent effectuer une recherche et un tri sur dates de commande. Il existe un index non unique sur ce champ pour accélérer la recherche et le tri.
Noms de table et de champ Vous pouvez nommer les éléments comme vous le souhaitez, mais la cohérence est importante. Nous recommandons que les noms de table et de champ soient un ou plusieurs mots sans espace entre eux et aucun caractère spécial, comme une barre oblique (/), un signe dièse (#) ou un pourcentage (%). Par exemple, utilisez OrderDate, mais pas Order Date ; utilisez OrderNumber ou OrderNo, mais pas Order#.
Camelcase Mettez en majuscules les mots pour mettre en surbrillance des parties individuelles du nom, par exemple OrderDate, mais pas Orderdate ou orderDate.
Valeur obligatoire Ce principe met en évidence l’importance des règles métier pour une application. Certaines situations nécessitent des valeurs ou même des valeurs spécifiques dans certains champs. Par exemple, à quoi sert une commande sans connaître le client qui l’a placée ? Cela signifie que CustomerID est un champ obligatoire pour la table Orders.
Champs calculés Access prend en charge les champs calculés dans les tables, par exemple le champ Employees.FullName. Vous préférerez peut-être créer des champs calculés dans une requête plutôt que dans une table.
Champs de pièce jointe Access prend en charge les champs de pièce jointe, par exemple Employees.Picture, qui contient une image de l’employé. Les pièces jointes peuvent stocker des images, des documents, des e-mails et d’autres informations binaires. Les pièces jointes occupent beaucoup d’espace dans la base de données. il est plus efficace de stocker les pièces jointes sur un serveur de fichiers à la place.
Champs à valeurs multiples Comme leur nom l’indique, les champs à valeurs multiples stockent une ou plusieurs valeurs dans un seul champ, par exemple Employees.Title. Nous vous suggérons de les utiliser avec parcimonie, en particulier si vous souhaitez upsizer votre base de données. La plupart des autres systèmes de base de données n’en ont pas, ce qui nécessiterait beaucoup de travail.
Pour plus d’informations sur les types de données, consultez Présentation des types de données et des propriétés de champ.
Cette section décrit les fonctionnalités les plus importantes de chaque table. Pour passer en revue la conception d’une table, sélectionnez-la dans le volet de navigation, cliquez dessus avec le bouton droit, choisissez Mode Création, ou sélectionnez Outils de base de données > Relations, puis cliquez avec le bouton droit sur un objet de table. Pour plus d’informations, consultez Présentation des tables.
Important : Évitez d’utiliser des mots réservés qui peuvent entraîner des conflits de nommage. Pour plus d’informations, consultez En savoir plus sur les mots et symboles réservés Access.
Table Employees
Cette table stocke des informations sur les employés de Northwind.
|
Champs |
Description |
|
FirstName, LastName |
Les deux noms sont obligatoires et, dans Northwind, ils doivent être une combinaison unique. Dans la conception de la table, lorsque vous ouvrez la boîte de dialogue Index , vous pouvez voir que FirstName + LastName ont un index unique. Étant donné que FirstName et LastName sont indexés de manière unique, la table Northwind ne peut pas stocker deux employés portant le même nom. Dans d’autres situations, vous pouvez utiliser une règle métier différente. |
|
FullNameFNLN, FullNameLNFN |
Examinez la propriété d’expression des champs calculés pour voir comment Access combine des valeurs dans des champs calculés. Pour inclure une initiale du milieu, ajoutez-la à l’expression existante avec un espacement approprié entre les composants. |
|
Champs de téléphone |
La règle métier pour les téléphones est que la préférence des employés est plus pertinente que le type de service. Par conséquent, les numéros de téléphone principal et secondaire sont utilisés plutôt que la cellule, le bureau, la maison, etc. |
|
Salutation |
Salutation est un champ Texte court. Pour illustrer la fonctionnalité de champ à plusieurs valeurs dans Access, il s’agit d’une zone de liste déroulante avec une liste modifiable de valeurs prédéfinies. Les listes courtes et statiques comme celle-ci sont souvent candidates pour des champs à valeurs multiples, car elles ne changent pas beaucoup, voire jamais. |
|
Jobtitle |
JobTitle est un autre champ obligatoire. |
Table Clients
Cette table stocke des informations sur les clients de Northwind.
|
Champs |
Description |
|
CustomerName |
Les clients de Northwind sont des entreprises, et un nom de client est requis. Contrairement aux noms d’employés, toutefois, il n’est pas indexé de manière unique, ce qui permet à deux clients ou plus d’avoir le même nom. |
|
PrimaryContactFirstName, PrimaryContactLastName, PrimaryContactJobTitle |
Le prénom, le nom et la fonction du contact principal ne sont pas obligatoires, car les clients n’ont peut-être pas une seule personne comme contact principal. Les contacts peuvent ne pas donner leur poste pour une commande. |
|
BusinessPhone |
Northwind ne nécessite qu’un seul numéro de téléphone pour chaque client, bien que cela élimine la possibilité de capturer plusieurs numéros de téléphone pour les clients ou pour les contacts des clients. Dans des situations réelles, des règles d’entreprise plus complexes s’appliquent normalement aux informations de contact. |
|
Adresse, Ville État, ZIP |
Northwind a besoin d’une adresse pour expédier les commandes aux clients. Il n’existe qu’une seule adresse générique pour un client. Dans des situations réelles, les clients ont souvent des adresses de facturation, d’expédition ou d’autres adresses distinctes. Une règle métier différente pour votre organization nécessite des champs supplémentaires. |
|
Remarques |
Le champ Notes est un type de données Texte long, qui stocke jusqu’à 1 Go de texte. Cela vous permet d’entrer des commentaires détaillés sur les clients à utiliser dans des situations de commande ultérieures. |
Table Orders
Cette table stocke des informations sur les commandes de Northwind.
|
Champs |
Description |
|
OrderDate, ShippedDate, PaidDate |
Les commandes nécessitent trois dates. Ils sont tous de type date/heure, mais avec deux formats. OrderDate a à la fois une date et une heure, car vous pouvez être intéressé par l’analyse du volume de commandes pour différentes parties de la journée. Pour les deux autres dates, seule la date est requise. Une règle de validation de table pour ShippedDate et PaidDate garantit que ces dates ne sont pas antérieures à OrderDate. |
|
OrderStatusID |
Le status d’ordre indique où se trouve l’ordre dans le flux de travail Northwind. Les commandes passent par quatre phases : Nouveau > Facturé > Expédié > Fermé.La clé étrangère du OrderStatus actuel utilise OrderStatusID de la table de recherche de OrderStatus. L’utilisation d’une table de recherche Status garantit que seuls les quatre états prédéfinis peuvent être attribués à une commande. |
Table des détails de la commande
Cette table stocke des informations sur les détails des commandes de Northwind.
|
Champs |
Description |
|
OrderID |
Chaque élément de ligne de la table OrderDetails doit appartenir à une commande dans la table Orders. OrderID est une clé étrangère identifiant cet ordre. Comme indiqué précédemment, une commande contenant un ou plusieurs éléments de ligne illustre une relation un-à-plusieurs. |
|
IDProduit |
Chaque enregistrement de la table OrderDetails inclut le ProductID du Produit commandé. ProductID est une clé étrangère dans la table OrderDetails, identifiant ce Produit dans cette commande. Il s’agit également d’une relation un-à-plusieurs. |
|
OrderID+ ProductID |
Comme vous l’avez vu dans la table Employees, plusieurs champs peuvent avoir un index unique. L’index unique sur OrderID+ProductID dans la table OrderDetails garantit que chaque commande ne contient un produit qu’une seule fois. Lorsque vous ouvrez la feuille de propriétés Index à partir du ruban, vous pouvez voir cet index unique. |
Table Products
Cette table stocke des informations sur les produits de Northwind.
|
Champs |
Description |
|
ProductCode |
En plus de la clé primaire, ProductID, les produits Northwind ont un code de produit convivial et indexé de manière unique. Les employés font normalement référence aux codes de produit et non aux valeurs de clé primaire. Le code de produit est une valeur composite composée d’une désignation Catégorie et d’un nombre, par exemple, B-1 pour « Boisson », produit 1. |
|
Nom du produit, Description du produit |
En plus des noms de produits en texte court, une description de texte long s’applique aux produits. Cette valeur peut être utilisée dans une description de catalogue ou pour répondre aux questions des clients. |
|
PrixUnité |
Tous les produits sont vendus avec un prix unitaire pour chaque article, ce qui simplifie la base de données comme une vitrine de fonctionnalités. Dans la plupart des situations réelles, la tarification est souvent beaucoup plus complexe. |
Voir aussi
