Salut,
Les clés primaires cela me semble je pense simple, en prenant le Num pour N° Id du client / N° du magasin loueur / N° de la cassette.
(" Les secondaires sont des clés qui font la jonction entre 2 tables ") si j'ai bien suivi les cours.
Par contre les clés étrangères, ben gloups gloups 
Je vois pas trop ce que tu appel clé secondaire. Pour la clé primaire tu prends le problème à l'envers, lorsque tu construit un modèle il faut éviter de créer des clés dites artificiels (un numéro client, numéro de magasin), il faut respecter le cahier des charges pour les attributs, si on ne te demande pas de mettre un ID n'en met pas (tu verras qu'on peut ajouter ce type de clé lorsqu'on crée le modèle physique, qui te donnera ton code SQL), sauf si tu es obligé.
Donc pour ta clé primaire, commence par noter tous les attributs, puis ensuite cherche le, ou les attributs qui pourront te donner une clé primaire (tu auras souvent plusieurs possibilités possible, il faut que cette clé identifie de manière unique un enregistrement). Il faut aussi te dire que cela varie selon l'utilisation voulue. Imaginons que tu ais une table Personne, avec un nom, un prénom, une date de naissance, si tu as peu d'enregistrements, tu pourrais considérer qu'il n'y aura pas d'homonyme, donc {nom, prénom} serait ta clé primaire, mais cela ne marche pas si tu as beaucoup d'enregistrement, c'est une question de logique et d’interprétation.
La clé étrangère te permet de lier des tables entre elles, c'est un truc que tu verras tout le temps.
Pour la cardinalité, je verrais demain, car dons ton cours je viens de découvrir la lettre M que je n'ai pas vu dans les miens. Oups alors.
M ? Je pense que c'est juste un nombre, exactement comme N.
Tu verras la plupart du temps la cardinalité est assez simple, pour schéma par exemple il faut te demander (par rapport aux contraintes) :
Pour abonné - adresse,
Un abonné peut avoir combien d'adresse ? entre aucune et plusieurs, exactement 1, entre une et plusieurs, exactement entre 1 et 3, ...
De même, une adresse peut correspondre à combien de personnes ?
Et ça va te donner la cardinalité.
Pour Etat, tu peux utiliser une énumération, en gros il te faut "créer" un type de variable. Pour chaque attribut, il faut que tu mette son type, par exemple, type date, entier, flottant, string, etc.
Pour ton exercice tu dois (si je me trompe pas, j'ai pas vérifié) pouvoir relier entre elles toutes tes tables.
Une fois que tout seras bien en forme et clair, tu pourras en faire le modèle Entité-Association.
Une dernière chose, ne t'en fait pas (pour le moment) pour ce genre de choses : "une location n'est permise que si le client est en règle", "la consultation d'un client permettra d'obtenir son nom, son adresse, son nombre d'emprunts en cours, la liste des numéros de cassettes et des titres qu'il a actuellement empruntés;
- la consultation d'un genre permettra d'obtenir la liste des films de ce genre disponibles dans un magasin donné;
- périodiquement, on veut obtenir la liste des retardataires; on veut pour chaque cassette non retournée à temps les informations suivantes : nom et adresse du client, date de l'emprunt, numéro(s) de cassette et titre du (des) film(s) concerné(s);
- on veut pouvoir connaître pour chaque cassette (identifiée par une numérotation commune aux dix magasins) où elle est, quand elle a été mise en service, quel film y est enregistré, combien de fois elle a déjà été louée, et quel est son état (de très bon à mauvais)."
Il faut que tu mette en place les attributs et tables qui permettraient de faire ça, mais tu te pourras pas faire ce qu'ils disent tout de suite. (ça sera ensuite avec de l'algèbre relationnelle : des projections, restrictions, jointures, etc).
