+ Rispondi al messaggio
Visualizzazione dei risultati da 1 a 2 su 2

Modello entitÓ relazione

  1. #1
    Paolodocet non Ŕ in linea Novello
    Non riesco a capire alla perfezione che cosa si intenda per entitÓ. La definizione, la conosco ed Ŕ la seguente:

    Un'entitÓ Ŕ una classe di oggetti, i quali hanno caratteristiche(proprietÓ) comuni, e che ha esistenza autonoma ai fini dell'applicazione informatica di interesse.

    Bene, allora subito un esempio. Prendiamo in considerazione un'applicazione aziendale e le entitÓ CITTA', DIPARTIMENTO, IMPIEGATO, ACQUISTO, VENDITA.
    Io non capisco perchŔ IMPIEGATO sia un'entitÓ: un impiegato non esiste solo ed esclusivamente se esiste un lavoro da lui svolto? Quindi IMPIEGATO non Ŕ una classe autonoma, ma comunque dipende da qualcosa.
    Grazie a chi mi aiuterÓ a chiarire tali dubbi

  2. #2
    L'avatar di +m+
    +m+
    +m+ non Ŕ in linea Scribacchino
    Quote Originariamente inviato da Paolodocet Visualizza il messaggio
    Non riesco a capire alla perfezione che cosa si intenda per entitÓ. La definizione, la conosco ed Ŕ la seguente:

    Un'entitÓ Ŕ una classe di oggetti, i quali hanno caratteristiche(proprietÓ) comuni, e che ha esistenza autonoma ai fini dell'applicazione informatica di interesse.

    Bene, allora subito un esempio. Prendiamo in considerazione un'applicazione aziendale e le entitÓ CITTA', DIPARTIMENTO, IMPIEGATO, ACQUISTO, VENDITA.
    Io non capisco perchŔ IMPIEGATO sia un'entitÓ: un impiegato non esiste solo ed esclusivamente se esiste un lavoro da lui svolto? Quindi IMPIEGATO non Ŕ una classe autonoma, ma comunque dipende da qualcosa.
    Grazie a chi mi aiuterÓ a chiarire tali dubbi
    C'Ŕ un bel po' di confusione, anche terminologica.
    "Storicamente" (anni '70) si pensava di aver inventato il Sacro Graal con i database relazionali, e i proto-SQL.
    Operativamente le entitÓ e le relazioni non esistono, sono semplicemente la modellazione, o meglio UNA delle modellazioni, che vengono adottate per mappare un problema di archiviazione dati mediante gli strumenti classici degli RDBMS.

    "classe" e "oggetti" sono terminologie degli anni '80, relativi ai linguaggi object-oriented, ed al relativo riflesso sui c.d. database ad oggetti.
    ---
    Puoi avere, anzi in generale esistono, pi¨ modellazioni ER che descrivono lo stesso problema, e spesso la scelta dipende sia da gusti personali, che da abitudini, che da pattern ed antipattern, che addirittura da considerazioni di performances etc.
    Cosý come per progettare una "villa" puoi studiare tante soluzioni diverse, analogamente per i database.
    ---
    Nel tuo caso IMPIEGATO Ŕ un'entitÓ del tutto autonoma, oppure no, perchŔ potrebbe benissimo esistere un IMPIEGATO disoccupato, o inoccupato (sto pensando ai politici )
    ---
    Poi pure la definizione Ŕ quantomeno bizzarra, nel senso che come accennato mischia terminologia diversa, e si riferisce ad un'applicazione informatica (??) la quale non Ŕ che sia benissimo definita.
    ---
    Infine se ci riferiamo al mondo accademico allora c'Ŕ tutta una teoria, per lo pi¨ obsoleta nel 2014 ma sempre valida, da conoscere a menadito.

    Cos'Ŕ quindi un'entitÓ in uno schema ER? Semplice, quello che il progettista ritiene essere un "qualcosa" del quale vuole memorizzare le caratteristiche.

+ Rispondi al messaggio

Potrebbero interessarti anche ...

  1. Decisione sul'entitÓ principale in un DB
    Da Diego1966 nel forum Microsoft Access
    Risposte: 3
    Ultimo Post: 01-04-2019, 14:49
  2. stampa come su modello
    Da frugo nel forum Microsoft Access
    Risposte: 5
    Ultimo Post: 07-11-2013, 08:31
  3. Risposte: 0
    Ultimo Post: 16-01-2013, 23:05
  4. Risposte: 1
    Ultimo Post: 04-06-2011, 22:04
  5. Modello F24
    Da mastrix nel forum Visual Basic 6
    Risposte: 5
    Ultimo Post: 24-06-2008, 21:41