Aiuto per creazione database con Access!!! Per favore...

[Linus]

Ciao a tutti,

il mio capo in ufficio mi ha chiesto di fare un database in access e dato che un pochino ci capisco mi hanno chiesto di farlo...

Non so proprio da dove iniziare; un pò conosco access ma non so come strutturare il database con access.

Mi potete dare una mano?

Devo fareun database con questi dati.

Ci sono 4 compagnie assicurative e per ogni compagnia ci sono dei clienti, numero di poliza, ramo assicurativo, scadenza poliza, premio, provvigione.
Ovviamente tutto diviso per mesi.

Io devo fare delle query per scadenza, per ramo e compagnia..

Cioè devo fare in modo che se il capo vuole sapere quanti clienti scadono la poliza a gennaio, deve fare in modo di saperlo e così per compagnia, e per ramo (che può essere infortuni, salute, incendio...etc)

come si struttura il database? Sono disposto anche a farvi qualche regalino...davvero!!!

aspetto vostro aiuto.
L.

[Linus]

nessuno?

[ri]

dubito fortemente che qualcuno si metta a fare il tuo lavoro "per favore", mi spiace

[Linus]

Originariamente inviato da ri

dubito fortemente che qualcuno si metta a fare il tuo lavoro "per favore", mi spiace

hai ragione di questo mi scuso...

ma sai, sono 5 anni che frequento questo forum, sono uno dei vecchietti e ho sempre aiutato un sacco di utenti e una volta che chiedo un aiuto io...mi sento quasi in colpa!!

beh, volevo almeno sapere ad esempio come strutturarlo, quante tabelle dovrei usare, etc...tutto qui...

[motogpdesmo16]

a mio modesto parere una cosa del genere non si può fare gestendola solo mediante le query di access ma è necessario interfacciarla con un linguaggio di programmazione.
Io ho realizzato un programma simile che tiene conto delle fatture: da una combo si può scegliere il fornitore e poi, per il fornitore selezionato, appaiono tutte le sue fatture ed è possibile anche scegliere un intervallo di date in cui effettuare la ricerca delle fatture.
Diciamo che è un po' quello che si adatta alle tue esigenze ma, come ti hanno già detto, non penso che qualcuno si metta a svolgere il tuo lavoro. Io per primo ci ho lavorato quasi 1 mese (lavorando solo 1 oretta la sera e giusto il pomeriggio della domenica) per terminarlo.
Più che altro ti chiedo: non hai alcuna nozione di basi di dati??
Nel senso: presentato un problema, sapresti almeno riconoscere dove ci vuole una tabella?

[Luca69]

Crea una tabella "compagnie_assicurazioni" per la descrizione delle 4 compagnie assicurative.
Ogni cliente ha una sola poliza? Nn credo. Quindi crea una tabella "descrizione_clienti" con i dati dei clienti.
Quindi crea una terza tabella "polize" che fa riferimento alla due tabelle precedenti e che contiene i dati delle polize x cliente x compagnia assicurativa.

Questo é quello che ti posso suggerire dalle poche info che hai dato.

Per quanto riguarda poi l'inserimento dei dati e la creazione di report, dipende da chi userá il DB.
Se sei solo tu, puoi inserire i dati direttamente nelle tabelle e poi crearti delle query per estrarti i dati che ti interessano. Il risultato sará una specie di foglio Excel ma senza formattazione.

Se invece vuoi qualcosa si piú robusto, devi creare dei From e un po' di codice in VB per l'inserimento dei dati e poi creare dei Report. Non é difficile se hai un po di familiaritá con VB.

[motogpdesmo16]

@luca69:è una soluzione coerente cone le poche info fornite.
Però dovrebbe inserire chiavi primarie/esterne e joinarle tra loro. Dubito che riesca a farlo da solo visto che non è riuscito ad individuare le tabelle.
Tuttavia, se esplica meglio ciò che vuole, non è escluso che qualcuno possa aiutarlo almeno nel diagramma E/R del DB.

[Fenomeno85]

Originariamente inviato da motogpdesmo16

a mio modesto parere una cosa del genere non si può fare gestendola solo mediante le query di access ma è necessario interfacciarla con un linguaggio di programmazione.

Con cosa interroghi se non con le quary un db? con select e compagnia bella fai tutto.
Che poi usi un linguaggio quelli son altri motivi ma tanto gli passi al dbms sempre istruzioni sql.

~§~ Sempre E Solo Lei ~§~

[motogpdesmo16]

Originariamente inviato da Fenomeno85

Con cosa interroghi se non con le quary un db? con select e compagnia bella fai tutto.
Che poi usi un linguaggio quelli son altri motivi ma tanto gli passi al dbms sempre istruzioni sql.

~§~ Sempre E Solo Lei ~§~

ovvio che con la query di access ottieni i risultati che ti servono. Solo che tenerle in access, imho non è molto funzionale. Non credi?

[PFed]

Originariamente inviato da Linus

Ci sono 4 compagnie assicurative e per ogni compagnia ci sono dei clienti, numero di poliza, ramo assicurativo, scadenza poliza, premio, provvigione.
Ovviamente tutto diviso per mesi.

Alt.
Qui si apre un MONDO a parte!

Innanzitutto i rami! Sono rami di bilancio o rami di compagnia ? (i rami di bilancio sono decisi dall'isvap, di compagnia dalle singole compagnie)
E le polizze multirischi ? vanno sul ramo principale ? vanno imputate per premio di competenza sui due rami ?

I premi ... Netti ? Lordi ? Comprensivi di accessori e diritti o meno ?

La scadenza ... Annuale ? Totale ? Le polizze sono a premio unico anticipato ? Pluriennali a scadenza annuale ? Annuali con tacito rinnovo ?

E se la polizza è annullata la devo contare ?
E se è sinistrata ?

Le provvigioni sul netto o sull'imponibile ? All'agente, al subagente o al produttore ? e le hai a disposizione tutte queste informazioni ?

Inoltre... come fai ad avere i dati di 4 compagnie diverse ? Siete una capogruppo o un'agenzia multimandataria ?


Insomma.... se descrivi un pochino meglio la realtà e quello che ti serve, forse una mano te la si può dare!

[Fenomeno85]

Originariamente inviato da motogpdesmo16

ovvio che con la query di access ottieni i risultati che ti servono. Solo che tenerle in access, imho non è molto funzionale. Non credi?

penso che quello che sta facendo sia solo un compitino assegnato per esercitarsi. Usare un linguaggio di programmazione del tipo c/c++ significa studiarsi tutte le istruzioni per accedere a un determinato dbms e la cosa non mi sembra molto fattibile velocemente. Quindi ben venga studiare inizialmente su access che tanto accetta tranquillamente codice in sql.

~§~ Sempre E Solo Lei ~§~

[PFed]

Originariamente inviato da motogpdesmo16

ovvio che con la query di access ottieni i risultati che ti servono. Solo che tenerle in access, imho non è molto funzionale. Non credi?

E invece si.
La query salvata in access (Stored Queries - ovvero la versione povera delle store procedure! ) ha prestazioni leggermente migliori delle query create al volo nel codice e passate attraverso JET, inoltre tramite l'utilizzo dei parametri si riesce ad astrarle abbastanza facilmente.

Da codice quindi richiami solo il nome della query ed eventuali parametri, e non tutta la definizione della stessa!

Inoltre, ti permettono di dividere la logica di interrogazione con la logica del programma / interfaccia grafica.

[PFed]

Originariamente inviato da Fenomeno85

penso che quello che sta facendo sia solo un compitino assegnato per esercitarsi.

Parlava di ufficio e capoufficio, inoltre la complessita del tema proposto non fa assolutamente pensare che sia un compitino!

Originariamente inviato da Fenomeno85

Usare un linguaggio di programmazione del tipo c/c++

Vorrei ben vedere, è un'ambito totalmente diverso da quelli in cui si impiegano c e c++!!!!!

A seconda del tipo di complessità richiesta può essere un progetto sviluppabile in Access Stand Alone, e qualora la complessità aumentasse switch a VB6 o VB.NET (C# per i -c/c++/jav-isti)

[motogpdesmo16]

Originariamente inviato da PFed

E invece si.
La query salvata in access (Stored Queries - ovvero la versione povera delle store procedure! ) ha prestazioni leggermente migliori delle query create al volo nel codice e passate attraverso JET, inoltre tramite l'utilizzo dei parametri si riesce ad astrarle abbastanza facilmente.

Inoltre, ti permettono di dividere la logica di interrogazione con la logica del programma / interfaccia grafica.

se la metti sul punto di vista della "divisione di logiche" hai pienamente ragione. Ti dico infatti che all'inizio è meglio rimanere sul lato interrogazione.
Però, dato che sarà un db di una compagnia assicurativa (a meno che, come dici tu, non sia altro che il compitino) ritengo che una interfaccia grafica sia meglio rispetto all'sql puro...che ne pensi?

[Fenomeno85]

Originariamente inviato da motogpdesmo16

se la metti sul punto di vista della "divisione di logiche" hai pienamente ragione. Ti dico infatti che all'inizio è meglio rimanere sul lato interrogazione.
Però, dato che sarà un db di una compagnia assicurativa (a meno che, come dici tu, non sia altro che il compitino) ritengo che una interfaccia grafica sia meglio rispetto all'sql puro...che ne pensi?

scusa ma una compagnia assicurativa secondo te non chiama una ditta?!

~§~ Sempre E Solo Lei ~§~

[PFed]

Originariamente inviato da motogpdesmo16

se la metti sul punto di vista della "divisione di logiche" hai pienamente ragione. Ti dico infatti che all'inizio è meglio rimanere sul lato interrogazione.
Però, dato che sarà un db di una compagnia assicurativa (a meno che, come dici tu, non sia altro che il compitino) ritengo che una interfaccia grafica sia meglio rispetto all'sql puro...che ne pensi?

Che innanzitutto per me non è un compitino ma un progetto on the road!

Inoltre che (se come prerequisito c'è l'utilizzo di access) definirei basi dati e interrogazioni standard su access.

Poi mi preoccuperei della realizzazione dell'interfaccia grafica e della businness logic non db. Questi due aspetti possono essere realizzati, a seconda della complessita del progetto o con lo stesso Access e le sue form e report, o con uno strumento di sviluppo produttivo come il vb6!

[PFed]

Originariamente inviato da Fenomeno85

scusa ma una compagnia assicurativa secondo te non chiama una ditta?!

~§~ Sempre E Solo Lei ~§~

Dipende che deve fare.

Le richieste che sono state presentate possono tradursi in:

a) mi elabori i dati della base dati che già abbiamo e mi fai fare delle richieste al volo ?

b) mi crei un programma ex novo ad hoc ?

e infinite sfaccettature.

Bisogna vedere se chi chiede è un commerciale, un'amministrativo o un'attuario...

e soprattutto bisogna vedere se di compagnia effettivamente stiamo parlando, o se di semplice agenzia!

[Fenomeno85]

Originariamente inviato da PFed

Vorrei ben vedere, è un'ambito totalmente diverso da quelli in cui si impiegano c e c++!!!!!

A seconda del tipo di complessità richiesta può essere un progetto sviluppabile in Access Stand Alone, e qualora la complessità aumentasse switch a VB6 o VB.NET (C# per i -c/c++/jav-isti)

guarda che c/c++ si adatta alla grande
se non ricordo male boinc è in c++

~§~ Sempre E Solo Lei ~§~

[motogpdesmo16]

Originariamente inviato da PFed

Che innanzitutto per me non è un compitino ma un progetto on the road!

Inoltre che (se come prerequisito c'è l'utilizzo di access) definirei basi dati e interrogazioni standard su access.

Poi mi preoccuperei della realizzazione dell'interfaccia grafica e della businness logic non db. Questi due aspetti possono essere realizzati, a seconda della complessita del progetto o con lo stesso Access e le sue form e report, o con uno strumento di sviluppo produttivo come il vb6!

si scusami. ho erroneamente confuso il tuo commento con quello di fenomeno85.
anche per me comunque non si tratta di un compitino ma di un progetto vero e proprio.
Ormai forse la forma mentis che ho assunto in questo genere di applicazioni (visto che ne ho realizzate diverse) è dbAccess+VB6 e ho ormai preso una certa dimestichezza.

[PFed]

Originariamente inviato da Fenomeno85

guarda che c/c++ si adatta alla grande
se non ricordo male boinc è in c++

~§~ Sempre E Solo Lei ~§~

Ma chi è che ti paga per uno sviluppo in c++ che se fatto in vb6 ci metti un decimo del tempo ed è perfetto per il tipo di progetto (Semplice gestionale con gestione minimale della base dati, IN ACCESS PERDIPIU'!!)