Si un livre peut appartenir à plusieurs catégories, et qu'une catégorie peut avoir BEAUCOUP de livres, alors vous avez besoin d'une relation MANY to BEY en utilisant une table intermédiaire (quelque chose comme Books _JOIN_Categories).
Books
ID | BookName
Categories
ID | CategoryName
Books_Join_Categories
BookID | CategoryID
Si chaque ne possède qu'une seule catégorie, mais chaque catégorie peut avoir des livres NOMBREUX, alors la structure de votre relation actuelle (CategoryID dans le tableau Livres) devrait vous faire très bien.
Books
ID | CategoryID | BookName
Categories
ID | CategoryName
En fait, la deuxième option est probablement la meilleure. Une relation de plusieurs à plusieurs n'est probablement pas une bonne idée dans cette situation (à moins que le livre ne soit déchiré en deux pour être mis sur des étagères séparées). Si deux sections différentes "catégorie" nécessitent le même livre, alors chaque catégorie (section dans une bibliothèque) obtiendrait leur propre copie physique du livre. Signification de deux enregistrements de livre dans la base de données, chacun avec un CategoryID distinct
D'accord, de cette façon, vous pourriez avoir un livre appartenant à plusieurs catégories – BenW
Mais une relation plusieurs à plusieurs dans ce cas est une mauvaise idée. Comment un seul livre peut-il s'asseoir sur deux étagères différentes dans une bibliothèque? C'est essentiellement ce que vous faites avec une relation de plusieurs à plusieurs. –
en fait, une relation de plusieurs à plusieurs a un autre avantage dans la conception. il sépare clairement les "quelles sont mes entités" de "comment puis-je les utiliser". un livre est un livre, une catégorie est une catégorie, la relation catégorie/livre n'a rien à voir avec ce qu'est un livre – dweeves