\subsection{\textsc{Type de compte}, \textsc{Devise préférée}, \textsc{Moyen de paiement préféré}}

Un utilisateur a de nombreuses informations comme on a pu le voir précedemment.
Lors d'une transaction, les utilisateurs ont besoins d'avoir des informations relatives à une vente pour un vendeur et à un achat pour un acheteur.
Pour un vendeur, on a besoin d'une devise préférée car le montant de la transaction sera converti dans cette devise.
Pour un acheteur, les informations requises sont la devise préférée puisque le montant de la transaction doit être affiché en fonction de cette devise, le moyen de paiement préféré puisque la transaction se fera grâce à ce moyen que l'utilisateur peut modifier à tout moment et un type de compte qui amène ou non une réduction sur le montant de la transaction.

\emph{Cardinalitées de la relation \textsc{Devise préférée}} :
\begin{description}
    \item[\textsc{Utilisateur $\rightarrow$ Devise préférée} (1, 1)] : Un utilisateur a une seule devise qu'il peut modifier à tout moment. Lors d'une transaction, la devise de l'acheteur est convertit vers la devise du vendeur c'est pourquoi elle doit être unique.
    \item[\textsc{Devise $\rightarrow$ Devise préférée} (0, n)] : On génère inclue toute les devises existantes dans notre base de données. Une devise peut avoir un ou plusieurs utilisateurs. En effet, par exemple si aucun utilisateur utilise une devise, elle sera dans la base de donnée mais non-utilisée. Par contre, plusieurs utilisateur peuvent utiliser la même devise puisqu'une devise est la plupart du temps commune à un pays voir même à une association de pays. (euro)
\end{description}


\emph{Cardinalitées de la relation \textsc{Type de compte}} :
\begin{description}
    \item[\textsc{Utilisateur $\rightarrow$ Type de compte} (1, 1)] : Le compte d'un utilisateur correspond soit à un compte "découverte", "fidélité" ou "compulsif". Cela est décidé en fonction du choix de l'utilisateur donc il doit être unique sachant que un type peut entraîner un coup annuel pour obtenir des réductions.
    \item[\textsc{Correspondance type de compte $\rightarrow$ Type de compte} (0, n)] : Plusieurs utilisateurs peuvent partager le même type de compte puisque cela correspond à des offres de fidélités proposer à chaque utilisateurs qui ont un compte du type "découverte" dans le cas où ils ne souscrivent à aucune offre.
\end{description}


\emph{Cardinalitées de la relation \textsc{Moyen de paiement préféré}} :
\begin{description}
    \item[\textsc{Utilisateur $\rightarrow$ Moyen de paiement préféré} (1, 1)] : Un utilisateur choisi son moyen de paiement dans ses paramètres. Il peut l'actualiser à tout moment. Il est utilisé par défaut lors d'une transaction, il est donc unique.
    \item[\textsc{Correspondance type paiement $\rightarrow$ Moyen de paiement préféré} (0, n)] : Un moyen de paiement correspond donc à "carte bancaire", "paypal", etc. Plusieurs utilisateurs peuvent l'utiliser comme aucun. On inclue tous les moyens de paiement que l'on veut inclure dans notre site.
\end{description}


\subsection{\textsc{Adresse de livraison} et \textsc{Adresse de facturation}}

Lors d'une transaction, l'acheteur a besoin d'une adresse de livraison pour se faire livrer sa commande. En effet, on a besoin de donner l'adresse au transporteur pour qu'il puisse savoir où livrer la commande.
De plus, une adresse de facturation est requise car SequoiaPayment a besoin de cette adresse pour le "mailing commercial" puisqu'elle n'est pas forcément la même que l'adresse de livraison bien qu'elles puissent être identiques. (exemple : l'acheteur fait livrer un cadeau à une personne tierce)
\emph{Cardinalitées des relations \textsc{Adresse de livraison} et \textsc{Adresse de facturation} :}
\begin{description}
    \item[\textsc{Adresse $\rightarrow$ Adresse de livraison} (0, n)] : Une adresse peut être une adresse de facturation uniquement donc elle peut référer à aucune adresse de livraison. De plus une adresse de livraison peut être la même pour plusieurs utilisateurs puisque plusieurs personnes peuvent habiter à la même adresse et se faire livrer des commandes via SequoiaPayment.
    \item[\textsc{Utilisateur $\rightarrow$ Adresse de livraison} (1, 1)] : Un utilisateur a une unique adresse de livraison puisque cela correspond à l'adresse où il se fait livrer. Il en a donc besoin pour effectuer une commande et ainsi permettre la transaction relative à cette dernière d'avoir lieu.
\end{description}


\subsection{\textsc{Situation} : relation entre ville et adresse}

On a besoin de connaître la ville à laquelle se réfère une adresse puisque une adresse peut-être identique pour plusieurs villes. De plus, au niveau de l'association d'un transporteur à une commande, elle va dépendre de la ville rattachée à l'adresse de livraison du vendeur puisque la commande devra être retiré par le transporteur à cette dernière.
De plus, grâce à la position de la ville par rapport à la planète, on va pouvoir comparer les distances entre les différentes villes.

\emph{Cardinalitées de la relation \textsc{Situation} :}
\begin{description}
    \item[\textsc{Adresse $\rightarrow$ Situation} (1, n)] : Une adresse est forcément dans une ville et, comme dis précedemment, une adresse peut être commune à plusieurs villes.
    \item[\textsc{Ville $\rightarrow$ Situation} (0, n)] : On génère toutes les villes auxquelles ont associe des transporteurs, c'est pourquoi une ville peut ne contenir aucune adresse dans le cas où aucun utilisateur n'y habiterait mais qu'un transporteur y soit rattaché.
\end{description}


\subsection{\textsc{Localisation} : localisation des transporteurs}

Comme on a pu le voir dans les descriptions précédentes, on a besoin d'associer des transporteurs à des commandes en fonction de l'adresse de livraison des vendeurs.
Pour ce faire on associe un transporteur à la ville la plus proche de son centre de livraison (cela se fait en interne donc nous n'avons pas besoin d'avoir les informations sur le centre de livraison).

\emph{Cardinalitées de la relation \textsc{Localisation} :}
\begin{description}
    \item[\textsc{Transporteur $\rightarrow$ Localisation} (1, 1)] : Un transporteur a obligatoirement une unique ville à laquelle il est associé puisque cette ville représentera l'emplacement du transporteur sur la planète.
	Dans le cas où un même transporteur est présent dans plusieurs villes d'un pays ou même de la planète, on créera plusieurs transporteurs auxquels ont associera toutes les villes puisque le téléphone et/ou l'adresse e-mail peuvent être différents.
    \item[\textsc{Ville $\rightarrow$ Localisation} (0, n)] : Comme dis précedemment, une ville est générée pour chaque transporteur mais il y a aussi les villes reliées aux adresses des utilisateurs. Une ville d'un utilisateur peut ne pas avoir de transporteur associé puisque dans le cas d'une transaction on s'intéressera à la ville la plus proche et non à la ville identique à l'adress de livraison du vendeur.
	De plus, on peut associer plusieurs transporteurs à une même ville pour pouvoir laisser le choix à l'utilisateur de choisir ou non son transporteur. (que ce soit l'acheteur ou le vendeur)
\end{description}