Conception Bases de données

Problématique : Automatisation d'une partie du SI d'un établissement client.

Introduction

Le système d'information (SI) de l'établissement est constitué de l'ensemble des documents, informatisés ou non,
des applications, des traitements relatifs aux données métier.

Domaine

Généralement, l'informatisation ne concerne pas tout le SI, mais l'un de ses domaines :

L'objectif de l'étude est de déterminer le champ des données à informatiser et à mémoriser, dans le but de comprendre le domaine du SI étudié.

Au travers d'entretiens (avec le client et les utilisateurs), de réunions, de collecte d'informations, on établira les règles de gestion du SI.

Notion d'entité du SI

Une entité représente un type d'objet du SI, matériel ou immatériel, ayant des propriétés spécifiques, et dont les occurrences sont potentiellement identifiables.

Les règles de Gestion vont permettre la description de ces entités, en définissant leurs caractéristiques :

leurs propriétés,
parmi les propriétés, celle qui peut éventuellement servir d'identifiant naturel,
les liens existants entre entités, qualifiés d'associations

Toute entité a obligatoirement un identifiant.
En l'absence d'identifiant naturel, il sera nécessaire d'ajouter une propriété jouant le rôle d'identifiant (artificiel), dont l'unicité sera souvent assurée par un auto-incrément (dont la valeur sera générée automatiquement par le SGDB utilisé).

Règles de gestion : Exemple

Nos assurés ont un nom, un prénom, des coordonnées de contact, et une adresse complète. Nous les identifions par un numéro unique.

Ils peuvent souscrire des contrats dans le cadre desquels ils assurent un véhicule.

Analyse des données et niveaux d'abstraction

L'analyse des données commence au niveau conceptuel (celui où nous manipulons les concepts métiers : l'assuré, le contrat, le véhicule…).

L'objectif est de modéliser (créer un modèle) le domaine du SI étudié.

Avantages liés au niveau conceptuel :

Les concepts sont connus et maîtrisés du client.
L'approche ne requiert pas de connaissances techniques.
Le modèle fourni est visuel et sera lisible de toutes les parties (MOA-client et MOE).
Le modèle permettra dans les étapes suivantes de générer la base de données.

Voir Niveaux d'abstraction

Dans la plupart des cas, la seule lecture des règles de gestion suffit à repérer les futures entités et associations du MCD, à trouver les identifiants et les propriétés.
Mais il arrive que dans certains cas, il soit moins évident de placer une données dans le MCD : il faut recourir dans cette situation à l'analyse des dépendances fonctionnelles.

Soit une relation R(P1, P2, …Pn) et A et B des sous ensembles de P1, P2, …Pn.

Il existe une dépendance fonctionnelle entre A(source) et B(cible) si et seulement si La connaissance d'une valeur de A quelconque permet de connaître le seul B associé.

Notation : A⇒B

Exemple : Soit la relation suivante :

Personne(NSS, Nom, Prénom, Marque, Type, Puiss, Date, Prix)

Lister les dépendances fonctionnelles la constituant.

Axiomes d'Armstrong (W)

Réflexivité

AB⇒BA
AB⇒B
AB⇒A

Augmentation

si A⇒B, alors quelque soit Y, AY⇒B

Transitivité

si A⇒B et B⇒C alors A⇒C

Régles de passage des dépendances fonctionnelles au modèle conceptuel de données (le MCD étant soit un MEA soit un diagramme de classes UML).

`A ⇒ B`	B est supposé ne pas être un identifiant. Nelle entité dont A est l'identifiant et B une propriété
`C ⇒ A`	C est un identifiant. CIF entre A(fils) et C(père)
`C,D ⇒ E`	C et D sont des identifiants. CIM entre C et D, porteuse de la donnée E