Bases de données

SQLite plus utilisé car plus léger et facilement maniable (juste fichier)

Modèle conceptuel de données (MCD) ==> modélisation du point de vue purement conceptuel
Modèle logique des données (MLD) ==> modélisation de la problématique du point de vue des
donnes

NOsql => données sous forme structuré mais sans requêtes

dbs oriente objet

MERISE = > méthode francaise (pas standardisé)

UML => norme

MCD (par rapport au cahier des charges)--> MLD (appliquer des méthodes sans "réflechir")

Entitées --> population d'individus homogènes (c'est un peu une classe en UML, ex: tous les
produits vendus par une entreprise peuvent etre regroupé sous une "classe" Article )

Association ==> liaison avec une signification précise entre plusieurs entitées

Attribut => propriété d'une entitée ou d'une liaison

identifiant => attribut unique pour chaque individu de l'entitée

cardinalités => 1 article peut etre commandé par 0 ou n clients (1 client peut commander 1 ou n
articles) (cf slides) merise dans l'autre sens

REGLES DE NORMALISATION :

1/ (Normalisation des entités) Toutes les entités qui sont remplaçables par une association,
doivent être remplacées. (cf slides)

2/ (Normalisation des noms) Nom d'une entité ou d'un attribut doit être unique

3/(Normalisation des id) chaque entité doit avoir un id ==> éviter les noms composés / éviter les
id susceptibles de changer au cours du temps/ le meilleur c'est un nbre qu'on incrémente de 1

4/ (Normalisation des attributs) éviter les attributs calculables à partir d'autres attributs /
remplacer les attributs en plusieurs exemplaires en une association de cardinalité maximum, n

clé primaire => permet d'identifier de manière unique une ligne dans une entitée (par
convention on la souligne)
clé étrangère =>contrainte qui s'assure du respect de l'intégrité référentielle de la base de
données

MCD -->MLD

Règle 1 => Toute entité devient une table / Tous les attributs deviennent des colonnes. /
L’identifiant de l’entité constitue la clé primaire de la table

Règle 2 => Une association de type 1:n disparaît au profit d’une clé étrangère dans la table
côté 1. / Cette clé étrangère référence la clé primaire de la table côté n.

Règle 3 => Une association de type n:m devient une table supplémentaire dont la clé primaire
est composée de deux clés étrangères (références aux clés primaires des deux tables). / Les
attributs deviennent les colonnes de cette nouvelle table

Règle 4 => Une association de type 1:1 se traduit comme une association de type 1:n sauf que
la clé étrangère se voit imposer une contrainte d’unicité (unique). / La clé étrangère se place du
côté opposé au côté 0,1

Règle 5 => Une association non binaire est traduite par une table supplémentaire dont la clé
primaire est composée d’autant de clés étrangères que d’entités en association