Conception de bases de données multimédias

Transcription

1 Conception de bases de données multimédias

2 Plan du cours Difficultés associées à la représentation d'objets MM (6.1) Modélisation conceptuelle (UML-ERD) (6.2) Transformation du modèle conceptuel en un modèle logique relationnel (6.2.1)

3 Difficultés en modélisation multimédia Temps Durée Synchronisation

4 Difficultés de la représentation MM Nombre et variété des dimensions caractérisant un objet MM dimension spatiale dimension temporelle dimension hiérarchique dimensions du contenu dimensions des objets (régions) dimensions des relations entre ces objets dimension technique : métadonnées acquises automatiquement lors de la capture de l'objet MM une vidéo incorpore toutes ces dimensions

5 Difficultés de la représentation MM Dimension temporelle ordre temporel : l'ordre entre les images d'une vidéo est essentiel gestion des intervalles de temps pouvoir comparer des séquences entre elles : se chevauchent-elles, l'une est-elle incluse dans l'autre, l'une se produit-elle après l'autre? gestion de la notion de durée synchronisation (vidéo) : bande sonore et images

6 Difficultés de la représentation MM Dimension spatiale gestion d'un système de coordonnées à 2 ou 3 dimensions gestion de volumes, surfaces, lignes et points nécessite des opérateurs de comparaison particuliers (comparaison d'objets selon leur position) points : l'un est-il à droite/à gauche/au-dessus/audessous de l'autre? surfaces : l'une est-elle contenue dans l'autre, chevauche-t-elle l'autre;

7 Difficultés de la représentation MM Dimension hiérarchique vidéo = séquence de clips clip = séquence de scènes scène = séquence de prises de vue livre = séquence de chapitres chapitre = séquence de sections section = séquence de paragraphes paragraphe = séquence de phrases phrase = séquence de termes (unités syntaxiques)

8 Difficultés de la représentation MM Incorporer des vidéos/bandes sonores/ images/textes à un modèle de données BD classiques (info de gestion) le problème se pose également lors de l'incorporation de données préexistantes à un système mais ensuite, les données sont généralement acquises pour s'intégrer au système pour un certain temps car les besoins d'affaires évoluent un objet MM est créé pour lui-même, et non dans le but d'être incorporé à une BDMM; il n y a donc pas de notion de besoins qui évoluent de la même manière

9 Plan du cours Difficultés associées à la représentation d'objets MM (6.1) Modélisation conceptuelle (UML-ERD) (6.2) Transformation du modèle conceptuel en un modèle logique relationnel (6.2.1) Définition de types de données utilisateur TDU (6.3) Manipulation de TDU (6.3.1) Introduction aux types Oracle InterMedia

10 Analyse : modèle conceptuel de données Modèle conceptuel de données représentation graphique abstraite des informations à placer dans la BD indépendante de la technologie utilisée pour l implémentation Sans modélisation conceptuelle c est le chaos d une conception hasardeuse!

11 UML et Oracle Designer UML indépendant des implémentations Utilisé dans les standards internationaux comme MPEG Notation pour représenter l'analyse et la conception de systèmes informatiques dans leur ensemble les données en sont l'une des composantes issue du monde de l'oo (Orienté-Objet) idéal pour conception en OO mais permet de modéliser n'importe quel type de BD Oracle Designer Notation particulière au fournisseur Notation mixte de ERD et OO Supporté par des outils de conception et génération automatisée Très répandu dans le marché actuel

12 Conception OO et ERD L industrie n en est pas au BD-OO Les modèles commerciaux actuels n appliquent pas la notion BD-OO Les difficultés avec les BD-OO ont considérablement ralenti le déploiement Actuellement c est le relationnel-objet (RO) qui a le marché!

13 UML

14 Conceptuel UML: notions de base Relationnel-Objet représentation d'une entité du monde extérieur (un utilisateur) ou de l'environnement informatique (un menu) un objet a une identité, distincte et permanente, représenté par un OID unique à travers la BD un état, représenté par des propriétés, changeantes avec le temps des comportements (impliquant un changement d'état) et des opérations associées

15 Conceptuel UML: notions de base Type/classe : ensemble des attributs et opérations caractérisant le comportement d'un groupe d'objets Attribut/propriété simple/composé : nom / adresse mono/multivalué : nom / téléphones de base/dérivé : date de naissance / âge l'âge peut être déterminé par une opération impliquant la date de naissance et la date du jour

16 Notion d'objet et de classe Objet (instance d'une classe) significatif pour le domaine d'application caractérisé par identité état comportement Attribut (variable membre, variable d'instance) contenant pour une valeur représente son état

17 Conceptuel UML: notions de base Un objet est représenté par un rectangle La partie supérieure contient le nom de l objet qui doit être souligné Le centre est la liste des attributs, leurs types et leurs valeurs

18 Conceptuel UML: notions de base Un objet a un état déterminé par les valeurs de ses attributs L état peut être modifié par un programme en modifiant les valeurs de ses attributs

19 Représentation d un objet en UML 7902:Employee Fig 6.4 Name : String = Ford Salary : Integer = 1756 Start_date : Integer = 03-May-1999 Picture : Blob = 7902.jpeg

20 Classe UML Une classe est une abstraction qui représente les caractéristiques communes à un ensemble d'objets Attributs Associations Opérations

21 Représentation d une classe en UML Employee Name: String Salary : Integer Start_date : Integer Picture : Blob changesalary changename Fig 6.5

22 Exemple : classes et objets CLASSE attributs opérations Objet : CLASSE attributs Vidéo titre date sujet durée segmenter compresser : Vidéo titre : Bugs Bunny sujet : Carrot Cake durée : 4min:20sec

23 Identifiant d'objet (OID, object identifier) Mécanisme d identification pas deux objets avec le même OID Implicite non visible (n est pas représenté explicitement dans le diagramme) réalisation traitée à l instanciation Mécanisme de référence

24 Pas besoin d identificateur explicite! Par opposition au relationnel OID = OID = : Prêt dateprêt : date = 10/10/2000 : Prêt dateprêt : date = 10/10/2000

25 Identifiant naturel (ou clé «key») pour une classe Ensemble minimal d'attributs qui identifie chacun des objets de manière unique {} ~ clé candidate du relationnel Représentation par une contrainte UML (contrainte de l attribut) Membre {UNIQUE:idMembre, UNIQUE:nom, prénom} idmembre nom prénom téléphone Ici deux objets membre ne peuvent pas avoir les mêmes valeurs pour l attribut

26 Syntaxe générale pour la spécification des attributs en UML [visibilité] nom [multiplicité] [: type] [= valeurinitiale] [{propriétés} ] visibilité peut être : + # - publique protégé privé nom de l'attribut multiplicité ( [1..1] par défaut) téléphone[1..2]: String adresse [0..1]: String auteurs [1..*]: String

27 Syntaxe pour attributs (suite) [visibilité] nom [multiplicité] [: type] [= valeurinitiale] [{propriétés}] type : OCL (Object Constraint Language) Boolean, Integer, Real, String, enum{valeur1,, valeurn} types de la plate-forme visée type non pré-défini classe stéréotypée «datatype»

28 Notion de lien et d'association binaire Lien Vidéo Lien est annoté par Contenu Est encadré Frame Personne Évènement Endroit Objet Association Vidéo Clip Séquence Prise 1..*.1 1..*.1 1..*.1 contient contient contient

29 Agrégation Cas particulier d association 0..1 A u to Association Optionnelle Prise (shot) 0..* 0..1 Séquence 1 1 2,4 4 M o te u r C h â s s is P o rte P n e u Clip 0..* 0..1 Une association entre un tout et ses parties = agrégation

30 Classes associatives Association plusieurs à plusieurs (fig 6.7) E tu d ia n t C o u rs nom p ré n o m * * s ig le titre Incorrect si plusieurs notes pour un Etudiant et un Cours N o te O b te n u e n o te s e s s io n Cette situation existe en tout temps dans les relations + à +.

31 Suite de l exemple Si il y a plusieurs notes pour un Étudiant et un Cours E tu d ia n t n o m p ré n o m 1 C o u rs s i g le titre 1 * N o te O b te n u e n o te s e s s io n *

32 Lien d héritage P e rs o n n e nom p ré n o m a d re s s e té lé p h o n e R é s id e n c e CaractVisuel le Couleur Texture E m p l oy é c o d e M a tric u le té lé p h o n e B u re a u E tu d ia n t c o d e P e rm a n e n t Une relation de généralisation est notée par un triangle

33 ERD

34 Conceptuel Entité-Associations: notions de base Entité Quelque chose de significatif pour l entreprise pour lequel des données doivent exister Même concept qu un objet Possède des instances Possède des attributs Possède des relations Ne possède pas de OID; doit avoir un identifiant Outils Designer qui génère la BD pour vous!

35 Représentation d un entité avec Oracle Designer Vidéo *Numéro *Date o Titre o description Attribut obligatoire Attribut optionnels

36 Représentation d un relation avec Oracle (fig 6.1) Un vidéo possède 1 ou plusieurs Clip(s) Vidéo Clip *Numéro *Date o Titre o description POSSÈDE APPARTIENT *Numéro o description Un vidéo possède 0 ou 1 clip POSSÈDE APPARTIENT Relation obligatoire (Un clip appartient à 1 et 1 seul vidéo)

37 Lire les relations Vidéo *Numéro *Date o Titre o description POSSÈDE APPARTIENT Clip *Numéro o description Un vidéo possède 0 ou 1 clip Un clip appartient à 1 et 1 seul vidéo

38 D autres exemples de relations ERD [min..max][min..max] [1..1] [1..1] [1..1] [0..1] [0..1] [1..1] [0..1] [0..1] [1..1] [0..*] [0..1] [0..*] [0..1] [1..*] [1..*] [1..*]

39 Plusieurs à Plusieurs Vidéo *Numéro *Date o Titre o description POSSÈDE Attribut de la relation (quantité) APPARTIENT Client *Numéro o nom En réalité, il s agit de deux relations distinctes Vidéo *Numéro *Date o Titre o description Un vidéo en particulier Un client en particulier Client *Numéro o nom

40 Plan du cours Difficultés associées à la représentation d'objets MM (6.1) Modélisation Conceptuelle (UML-ERD) (6.2) Transformation du modèle conceptuel en un modèle logique relationnel (6.2.1) Définition de types de données utilisateur TDU (6.3) Manipulation de TDU (6.3.1) Introduction aux types Oracle InterMedia

41 Le modèle logique Transformation "mécanique" du schéma conceptuel en un schéma logique Ici schéma logique relationnel Oracle Assure la compatibilité de l'analyse conceptuelle avec le modèle physique de BD retenu En relationnel, colonnes uniquement simples et monovaluées

42 Le schéma logique : règles de normalisation Transformation des classes en tables Transformation des associations N:N (création d entité d intersection) Transformation des associations 1:N (ajout clé étrangère côté N) Transformation des hiérarchies

43 Le schéma logique : règles Transformation des classes en tables Choix des clés primaires : invariantes, sans structure interne ni signification externe, de petite taille Projets Id_projet Nom_projet Statut Périodes Id_période Date_début Date_fin Statut Employés Id_employe No_employe Matricule Nom_employe Prénom Code_usager Taux_horaire_base

44 Le schéma logique : règles Transformation des classes en tables (suite) Choix des clés primaires : invariantes, sans structure interne ni signification externe, de petite taille Transformation des attributs structurés monovalués en plusieurs champs : adresse -> rue, ville, province, code_postal EMPLOYÉ NoEmpl NomEmpl Adresse Diplômes EMPLOYÉ NoEmpl NomEmpl Numéro Rue Ville Province CodePostal Pays Diplômes

45 Le schéma logique : règles Transformation des classes en tables (suite) Transformation des attributs multivalués en tables auxiliaires avec ajout d'une clé étrangère vers la table principale : table des téléphones EMPLOYÉ NoEmpl NomEmpl Numéro Rue Ville Province CodePostal Pays Diplômes possède (0,N) DateObtention Institution est possédé par (0,N) DIPLÔME NomDiplôme Spécialisation

46 Le schéma logique : règles Transformation des associations N:N

47 Le schéma logique : règles Éliminer les attributs d association

48 Le schéma logique : règles Transformation des associations 1:N

49 Le schéma logique : règles Transformation des associations 1:N

50 Le schéma logique : règles Traduction des hiérarchies : trois approches 1. Délégation : une table par classe 2. Fusion : fusion du parent et des enfants; une seule grande table 3. Concaténation : duplication des colonnes du parent dans chaque enfant; la table parent est éliminée

51 Le schéma logique : règles 1. Délégation : une table par classe Personne nopersonne : Integer nom : String prénom : String ville : String Personne {Clé primaire: nopersonne} nopersonne : Integer nom : String prénom : String ville : String catégoriepersonne : Char {disjointe, complète} Employé Étudiant Employé Étudiant noemployé : Integer salaire : Decimal codepermanent : Integer programme : Integer {Clé primaire: noemployé} noemployé : Integer salaire : Decimal nopersonne : Integer {Clé primaire: codepermanent} codepermanent: Integer programme : Integer nopersonne : Integer Attribut discriminant optionnel Jointures obligatoires

52 Le schéma logique : règles 2. Fusion : une seule grande table Employé noemployé : Integer salaire : Decimal Personne nopersonne : Integer nom : String prénom : String ville : String {disjointe, complète} Étudiant codepermanent : Integer programme : Integer Personne {Clé primaire: nopersonne} nopersonne : Integer nom : String prénom : String ville : String catégoriepersonne : Char noemployé : Integer salaire : Decimal codepermanent: Integer programme : Integer Attribut discriminant obligatoire

53 Le schéma logique : règles 3. Concaténation : une table par enfant Personne nopersonne : Integer nom : String prénom : String ville : String Employé {Clé primaire: noemployé} noemployé : Integer nom : String prénom : String ville : String salaire : Decimal Employé noemployé : Integer salaire : Decimal {disjointe, complète} Étudiant codepermanent : Integer programme : Integer Étudiant {Clé primaire: codepermanent} codepermanent: Integer nom : String prénom : String ville : String programme : Integer