[Class Diagram]Problemi di progettazione

di il
17 risposte

[Class Diagram]Problemi di progettazione

Salve a tutti, ho un problema nella progettazione di una Base di Dati(Relazionale) che deve gestire un negozio di abbigliamento, quindi eventuali vendite e disponibilità di magazzino. Ho creato una prima bozza del class diagram ma non mi convince e dubito della sua efficienza e completezza.
Questa è la bozza
Questa è la bozza

17 Risposte

  • Re: [Class Diagram]Problemi di progettazione

    1. Abituati a nominare le tabelle sempre al PLURALE.
    2. Non in tutte le tabelle è chiaro il campo "chiave primaria". Generalmente riporta l'iniziale ID. Quindi aggiungi IDCliente in Clienti, IDCapo in CapiAbbigliamento…
    3. Se interpreto bene:
    Clienti uno-a-molti Ordini: OK.
    Carrello dovrebbe essere il classico DettagliOrdini che fa da tabella di congiunzione tra Ordini e Articoli (nel tuo caso CapiAbbigliamento). Quindi secondo la relazione molti-a-molti dovresti avere le 2 relazioni:
    Ordini.IDOrdine uno-a-molti DettagliOrdini.IDOrdine
    CapiAbbigliamento.IDCapo uno-a-molti DettagliOrdingi.IDCapo
    Per capire meglio tutto questo, ti consiglio di dare un'occhiata al famoso database Northwind.
    4. Per tutto il resto non capisco cosa vuoi realizzare.
  • Re: [Class Diagram]Problemi di progettazione

    Ho apportato delle modifiche secondo i tuoi utili consigli e ti spiego anche che si tratta di un progetto universitario riguardo un applicativo java e il database relazionale di questo negozio d'abbigliamento con cui devo gestire vendite e disponibilità di magazzino.
    Io e il mio collega abbiamo deciso di implementarlo come se fosse un negozio online con molteplici magazzini. Credi servano ulteriori modifiche e/o aggiunta di classi?
    Inoltre ho inteso codice a barre di capo d'abbigliamento come idCapo.
    Allegati:
    Modificato
    Modificato
  • Re: [Class Diagram]Problemi di progettazione

    Ci sono molti simboli di cui non capisco il significato. Es.:
    +Del...+Fa
    1------------1
    Io sono abituato alla Finestra Relazioni di Access.
    Devi mettere il campo Clienti.IDCliente e Ordini.IDCliente e relazionare di conseguenza.
    Ti consiglio di mettere sempre un unico campo chiave primaria. Quindi aggiungi anche IDDettaglio in DettagliOrdini.

    Le 5 tabella a sinistra direi che vanno bene.
    Secondo me il Magazzino sarà soltanto la risultanza dei movimenti di Ordini/DettagliOrdini. Questo lo ottieni con le query.
  • Re: [Class Diagram]Problemi di progettazione

    I termini che non capisci vengono utilizzati per chiarire le associazioni ad esempio:
    Ordini del cliente
    Cliente fa ordini.
    Riguardo alla tabella Disponibilità ho dei seri dubbi in quanto non so che cardinalità inserire.
  • Re: [Class Diagram]Problemi di progettazione

    Io ragiono in altra maniera.
    1. Prova a pensare la tabella Clienti in RagioniSociali, perché possono essere anche Fornitori.
    2. La tabella Ordini in Movimenti, perché puoi avere movimenti in Entrata (da Fornitori) e Uscita (da Clienti).
    In questo modo puoi tracciare anche gli ingressi di Capi in azienda. Se aggiungi un campo TipoOrdine bivalore (Entrata/Uscita), dovresti risolvere il problema Magazzino che, come ti dicevo, lo ricavi da query di selezione e calcolo.
  • Re: [Class Diagram]Problemi di progettazione

    Ho degli ggiornamenti.
    In pratica la base di dati si riferisce ad un negozio fisico non online, dunque la tabella magazzino la riduco in un semplice attributo in capo d'abbigliamento (Disponibilita) che sarà bivalore con presente-assente. Riguardo l'aspetto dei fornitori non mi è chiesto di implementarlo ma lo userò come progetto personale in futuro.
    I miei dubbi ora vengono convogliati su quella tabella Qualità.
    Allegati:
    Nuovo
    Nuovo
  • Re: [Class Diagram]Problemi di progettazione

    Il Clinte esiste in quanto gli vendi i capi o è il Fornitore?
    A parte altri aspetti e indipendentemente dalla risposta sopra, manca o il carico o lo scarico del magazzino.
  • Re: [Class Diagram]Problemi di progettazione

    Il cliente esiste in quanto vendo i capi. Riguardo l'aspetto da te menzionato, credo di dover aggiungere una tabella 'Magazzino' con attributi per identificare la locazione degli indumenti e la loro disponibilità(altro aspetto che non so come trattare).
  • Re: [Class Diagram]Problemi di progettazione

    Manca la parte dei movimenti di carico che dovrebbe essere simile a quella della vendita, ovvero
    Clienti -> OrdiniClienti -> FattureCliente
    Fornitori -> OrdiniFornitari -> FattureFornitore
  • Re: [Class Diagram]Problemi di progettazione

    Ho aggiunto il fornitore ma non ho idea di come gestire la disponibilità in magazzino e le fatture
    Allegati:
    Rimodellato
    Rimodellato
  • Re: [Class Diagram]Problemi di progettazione

    Stifone ha scritto:


    Manca la parte dei movimenti di carico che dovrebbe essere simile a quella della vendita, ovvero
    Clienti -> OrdiniClienti -> FattureCliente
    Fornitori -> OrdiniFornitari -> FattureFornitore

    OsvaldoLaviosa ha scritto:


    Io ragiono in altra maniera.
    1. Prova a pensare la tabella Clienti in RagioniSociali, perché possono essere anche Fornitori.
    2. La tabella Ordini in Movimenti, perché puoi avere movimenti in Entrata (da Fornitori) e Uscita (da Clienti).
    In questo modo puoi tracciare anche gli ingressi di Capi in azienda. Se aggiungi un campo TipoOrdine bivalore (Entrata/Uscita), dovresti risolvere il problema Magazzino che, come ti dicevo, lo ricavi da query di selezione e calcolo.
    Per Stifone: hai provato a prendere in considerazione anche questa ipotesi? Credo che la mia risposta sia più NORMALIZZATA. Clienti e Fornitori hanno campi "simili". Di conseguenza possono essere rappresentati da un'unica tabella Aziende o RagioniSociali.
    Idem OrdiniClienti e OrdiniFornitori in Movimenti.
  • Re: [Class Diagram]Problemi di progettazione

    Ho aggiunto una associazione tra Cliente(fornitore) e capi..., e poi una relazione Fatture con cui CREDO di poter riuscire a gestire quelle per i clienti e per i fornitori. Cosa andrebbe migliorato e mi chiedo, dovrei implementare una relazione magazzino per sapere in che zona di quest'ultimo si trova il prodotto?
    Allegati:
    27808_75330df69bbe41cffce0dc992bdd4714.jpg
    27808_75330df69bbe41cffce0dc992bdd4714.jpg
  • Re: [Class Diagram]Problemi di progettazione

    Naturalmente sono solo indicazioni sommarie, le informazione da avere per gestire correttamente un database di questo tipo sono sicuramente di più, per esempio:
    • i Capi provenienti dal Fornitore arrivano sempre tramite Fattura o anche tramite Documento di trasporto
    • il Codice relativo al Capo rimane quello del Fornitore o una volta in Magazzino può cambiare
    • i Capi sono solo abiti o anche accessori abbinabili ad essi
    • i Clienti sono solo Persone fisiche (Codice fiscale) o potrebbero essere anche Persone giuridiche (Partita iva)
    • La consegna dei Capi ai Clienti vengono effettuati tramite :
      • Fattura
      • Documento di trasporto
      • Scontrino fiscale

    ecc...
  • Re: [Class Diagram]Problemi di progettazione

    Però quella creata da me, per un semplice progetto, andrebbe bene? va modificato qualcosa?
Devi accedere o registrarti per scrivere nel forum
17 risposte