Visualizzazione dei risultati da 1 a 5 su 5
  1. #1

    [OFF topic] Normalizzazione Schema e-r

    Salve a tutti,
    mi scuso in anticipo per la discussione non propriamente in tema ma volevo chiedervi un consiglio vista la mia inesperienza con i database in generale: sto sviluppando un database in access per un progetto scolastico che prevede la realizzazione prima dello schema e-r e poi del progetto logico.
    Vorrei chiedervi se il seguente schema, con la relativa ristrutturazzione, può considerarsi corretta o meno.

    VERSIONE PRELIMINARE



    SCHEMA RISTRUTTURATO



    Vi spiego: nel primo caso ho assunto che i clienti possono essere di due tipi (ditte o privati), ma la generalizzazione è parziale, ossia nel mio database voglio avere anche la possibilità di aggiungere a seconda delle mie esigenze nuove tipologie di clienti (Succursali, enti statali ecc). Così, nella ristrutturazione, invece che inserire direttamente un campo "Tipo" all'interno di "Clienti", ho creato una nuova entità che ha il compito di catalogare e associare tutte le tipologie di clienti creati.

    Alla fine ho il seguente modello logico tradotto:

    CLIENTI(ID, Nome, Cognome*, Partita IVA*, CF*, Indirizzo, Tipo:PROFILO)
    PROFILO (CODICE, Descrizione)

    con ID e CODICE come chiavi primarie, quelli senati con l'* come opzionali a seconda della tipologia del Cliente

    Credete che sia corretto questo passaggio?

    Grazie in anticipo per la collaborazione!

    Un neofita alle prime armi

  2. #2
    Utente di HTML.it L'avatar di anx721
    Registrato dal
    Apr 2003
    Messaggi
    2,352
    direi che è corretto

    Sun Certified Java Programmer

    EUCIP Core Level Certified

    European Certification of Informatics Professionals

  3. #3
    Utente di HTML.it L'avatar di newbie
    Registrato dal
    Dec 2005
    Messaggi
    299
    Dal punto di vista formale, non è molto corretto fare tutto in un passo solo. Bisognerebbe

    1) accorpare le entità nel padre, aggiungendo il campo "tipo" come attributo composto ID-Descrizione
    2) separare l'attributo composto in un'altra tabella (poichè nelle ristrutturazioni gli attributi composti vanno eliminati)

    Se vuoi evitare i due passi, dovresti almeno dire perchè hai accorpato in quel modo (sporco ma efficace).

  4. #4
    Grazie per la dritta: non mi è però chiaro quando dici accorpare le entità figlie nel padre: come faccio ad inserire ditta e privato all'interno di Clienti?
    Non basta che nel primo punto creo un nuovo attributo composto "tipo" (composto da id e descrizione) e riporto in cliente gli attributi CF, Nome e Partita IVA.
    Poi creo la tabella Profilo come nella seconda immagine.
    Ho sbagliato qualcosa?

    Grazie in anticipo!

    PS: inoltre è più corretto che nella relazione da Profilo verso Clienti non sia (1,N) ma (0,N), perchè alcuni profili posso essere presenti senza però essere necessariamente associati a nessun cliente, non trovi?

  5. #5
    Utente di HTML.it L'avatar di newbie
    Registrato dal
    Dec 2005
    Messaggi
    299
    Praticamente "accorpare le entità figlie nel padre" vuol dire, in burocratese, quello che hai già fatto, cioè trasformare la gerarchia in un'unica entità contenente gli attributi di padre e figlie. Il "Profilo", come hai detto tu stesso nel primo post, fa da "tipo" (che in teoria sarebbe un attributo, composto, di ogni elemento di Cliente), che hai messo in una tabella separata.
    A livello concettuale, cioè, non c'è niente di sbagliato. E' a livello formale che i prof potrebbero avere da ridire, nel senso che hai messo insieme due passi della progettazione (trasformazione delle gerarchie ed eliminazione degli attributi composti), e forse loro (compresi i miei) li vogliono vedere separati. Non conoscendoli, non so se separare i due passi serva o meno, comunque, per non rischiare, ti converrebbe almeno motivare la scelta.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.