Conception Bases de données

Ceci est une ancienne révision du document !

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é spécifiques, et dont les occurences 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

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.

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

Clé

Soient une relation R(A1,A2,…,An) et K un sous-ensemble de A1,A2,… ,An.

K est une clé de R si et seulement si :

K⇒A1,A2,…,An

il n'existe pas K’ inclus dans K tel que K’⇒A1,A2,…,An

Clés candidates & clé primaire

Une relation peut comporter plusieurs clés (elles sont qualifiées de clés candidates). L'une d'entre elles sera choisie pour être clé primaire.

Ne pas confondre plusieurs clés avec la notion de clé composite (cad constituée de plusieurs attributs)

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`	Nelle entité dont A est l'identifiant et B une propriété
`C ⇒ A`	CIF entre A(fils) et C(père)
`C,D ⇒ E`	CIM entre C et D, porteuse de la donnée E