Sviluppo Gestionale Rubinetto Felice

[Berserker79]

Ciao Gianluigi, che ne pensi di ritornare alla progettazione classica del database, lasciando stare le tabelle ereditate?

[Gianluigi]

Ciao Sotema,
in questa fase che prevederebbe la sola raccolta di tutte le voci per poter estrarre tutte le caratteristiche da riunire in tabelle sotto i soggetti individuati, parlare di tabelle ereditate, che oltre a tutto sei l'unico a conoscere, è prematuro. Lo so sono stato io a fare una fuga in avanti ma voleva essere di stimolo all'invio delle voci, volevo farvi capire che senza le voci non si può proseguire la progettazione ma nel contempo anche sollecitare un parere.
Io penso che almeno da questo punto di vista tu possa accettare di seguire una “normale” progettazione rivolta ai database relazionali, saremo sempre in tempo a innestare successivamente, laddove utile, l'eredità.
Non lo so, ma non penso che l'eredità sconvolga completamente la progettazione, penso che la coadiuvi e la integri.
Più volte vi ho chiesto di rimanere nel binario della progettazione, di seguirne il tracciato.
Non vedo altro modo per poter agire sensatamente.
Il metodo Hernandez non è altro che un sistema elementare di progettare il database relazionale nei canoni indicati dal suo inventore (Codd), come già detto l'unico che io sia in grado di seguire.
Una volta che noi avremo individuato tutte le tabelle e tutti i campi con tutte le relazioni corrette e funzionanti, con tutti i campi del corretto tipo e delle giuste dimensioni, con le regole di business soddisfatte, a quel punto potremo entrare nel discorso di come metterlo in pratica con PostgreSQL e Gambas.

Ciao Berserker79,
l'ultimo pdf allegato credeva di venire incontro alle tue richieste e non contiene nessuna tabella ereditata, vorrebbe essere un normale diagramma di relazioni fra tabelle, limitatamente alle anagrafiche aziendali.

Siate gentili, se avete delle idee diverse dalle mie su come deve essere costruito il database perché io non sono stato capace di creare un buon schema, basta schizzarlo a matita su un foglio, scannerizzarlo e allegarlo, come detto non serve che scriviate tutti i campi bastano quelli utili allo schema e allegare gli elenchi laddove siano variati rispetto agli ultimi inviati.
Lo so magari siete abituati a disegnare diagrammi ER ma questo è molto più semplice ed intuitivo e non serve alcuna preparazione e conoscenza, io non do alcun valore a come è disegnata la tabella serve solo a contenere i campi contano solo le linee di relazione che uniscono campi di diverse tabelle e il lato uno o quello molti.
Più avanti quando affineremo il discorso potremmo anche decidere di rappresentare le tabelle in modo diverso a secondo del tipo

  Ciao a tutti

PS. Caro Sotema ogni tanto una bella bevuta è proprio quello che ci vuole, forse non farà tanto bene ai database ma non ci giurerei 

[Berserker79]

Ciao Gianluigi,
dovresti rivedere la relazione fra anazie e ansedi, secondo me va tolta dalla tabella anazie il campo idsed, mentre va inserito nella tabella ansedi il campo idazi.
Come dice Sotema, su ansedi vanno inserite tutte le sedi dell'azienda diverse da quella legale, che va indicata nella tabella anazie.

Ma la tabella ansedi, dovrebbe contenere i dati delle sedi extra dei nostri clienti/fornitori o della nostra azienda?
Se è stata pensata per i nostri clienti/fornitori, credo che si possa evitare utilizzando solo le due tabelle principali clienti e fornitori.

[Gianluigi]

Ciao Gianluigi,
dovresti rivedere la relazione fra anazie e ansedi, secondo me va tolta dalla tabella anazie il campo idsed, mentre va inserito nella tabella ansedi il campo idazi.
Come dice Sotema, su ansedi vanno inserite tutte le sedi dell'azienda diverse da quella legale, che va indicata nella tabella anazie.

Ma la tabella ansedi, dovrebbe contenere i dati delle sedi extra dei nostri clienti/fornitori o della nostra azienda?
Se è stata pensata per i nostri clienti/fornitori, credo che si possa evitare utilizzando solo le due tabelle principali clienti e fornitori.

Ciao Berserker79,
non fare confusione, dovresti essere in possesso della cartella Relazioni aziende 20-01, la tabella ansedi altro non è che una tabella di convalida o come cavolo si chiamano quelle tabelle che distinguono il tipo di record, in questo caso per sapere se la sede è un ufficio, un magazzino, un laboratorio.
Occorre che leggiate i file allegati ai diagrammi che descrivono le tabelle e il loro contenuto e che dovreste avere la cortesia di ampliare completandole.
Altrimenti vanificate i miei sforzi e non riusciamo a chiarirci.
Se poi la parola ansedi vi è indigesta cambiamo pure nome alla tabella anche a tutte io non ne faccio un problema.
La sede centrale è nella tabella particolare anacli, anafor ecc. il rapporto fra questa e anazie è un rapporto di uno a molti e serve per non avere limiti nel memorizzarne i dati (uffici esterni, magazzini ecc.).
Ho invertito la relazione su tua richiesta e in effetti ora non avremo 3 campi di chiavi esterne vuoti per ogni azienda.
Con questo schema se non mi sbaglio clamorosamente dovremmo poter memorizzare tutto quello che ci serve, naturalmente mancheranno senz'altro delle voci di campo, ma se fate i bravi e me le indicate...
 

[Berserker79]

Se lo scopo della tabella anasedi è catalogare le varie sedi (siano esse magazzini o no) delle aziende contenute in anazie, allora dovrai registrarvi i dati fiscali di ciascuna sede;  se poi la sede di cui parliamo è un filiale di Rubinetto Felice il Numero REA, che sarà differente da quello della sede centrale qualora la sede sia residente in una provincia diversa, deve necessariamente essere registrato poiché deve comparire nei documenti fiscali emessi dalla filiale. Per chiarire il concetto :

Spedizione a Sede o Magazzino  di un cliente
Sui documenti fiscali dovranno apparire:
Per Rubinetto Felice
Ragione Sociale
Indirizzo Sede Legale (Via - Comune - CAP - Provincia)
Codice Fiscale e Partita IVA (qualora differenti devono apparire entrambi)
Numero REA
Numero CCIAA

Per il Cliente
Ragione Sociale
Indirizzo Sede Legale (Via - Comune - CAP - Provincia)
Codice Fiscale e Partita IVA (qualora differenti devono apparire entrambi)
Indirizzo di spedizione Merce (se diverso dall' indirizzo della sede legale)

I dati relativi alle sedi diverse dalla Sede Legale, li metti in anasedi, per non avere la tabella anazie piena di campi nulli.
Ovviamente i dati delle Sedi Legali saranno in anazie.

Ciao Gianluigi, secondo quanto ha indicato Sotema, avevo capito che la tabella ansedi avrebbe contenuto gli indirizzi di tutte le varie sedi di un'azienda, diverse  da quella legale.
Per questo ti avevo indicato di cambiare il tipo di relazione.

[Gianluigi]

  Carissimo Berserker79, 
hai ragione, ma io poi ho risposto a Sotema dicendogli che reputavo superato il diagramma a cui lui si riferiva in quanto basato su di un presupposto errato.
Penso che tutto sia nato perché avevo sbagliato la tabella ansedi derivata da anamag.
Avete tutti equivocato sul suo significato. Per me avete anche equivocato sulla tabella anazie.
Poi tu dicendomi di togliere i codici clienti, fornitori ecc. dalla tabella anazie, essendo ormai non più molto sveglio ho creduto di intravedere un escamotage nell'inversione della relazione.
Devo aver bevuto la stessa bevanda di Sotema.  Sarà il caso di cambiare fornitore. 
Io poi per sovrappiù avevo anche fatto colazione con pane e volpe. 

Attenzione battaglione, fra le miriadi di diagrammi da me fatti a vanvera forse l'unico che aveva una certa valenza è quello con le relazioni uno lato clienti, fornitori, vettori, organizzazione e i famigerati codici in anazie lato molti.
Lo riallego tanto per non confonderci (o per confonderci di più?).
Se non erro clamorosamente e se ho capito cosa mi ha detto Sotema Numero REA e Numero CCIAA servono solo per l'organizzazione (Rubinetto Felice) perché vanno sui documenti ufficiali.
Cambiano ogni volta che la sede periferica che può emettere documenti si trova fuori dalla provincia della sede.
Se, come io credo usi fare normalmente, l'organizzazione ogni volta che registra sul database una sede secondaria autonoma crea un nuovo record nella tabella principale (anoraz) ecco che non ci sarebbero problemi a usare l'ultimo schema da me proposto.

Le sedi, principali o secondarie che siano vengono registrate nelle tabelle anoraz per l'organizzazione, ma volendo anche per i clienti (anacli) i fornitori (anafor) e vettori (anavet).
La tabella generale anazie ha il compito di registrare i dati comuni anche a qualunque altro tipo di sede (di quale tipo si tratti sarà memorizzato con il supporto di ansedi).
I dati particolari delle sedi in anoraz, anacli, anavet, anafor. I dati comuni più gli indirizzi dei magazzini, laboratori ecc. in anazie.
Credo che quello che confonde sia il fatto che le tabelle principali mancano dei campi ragione sociale, indirizzo ecc.

Esempio pratico, devo registrare un nuovo cliente che ha la sede a Bergamo e il magazzino centrale  sempre a Bergamo ma in una via limitrofa a quella della sede (stesso palazzo) e in questo momento sta lavorando in più cantieri sparsi per l'Italia.
La maschera registrerà il codice in anacli insieme al tipo di cliente e agli eventuali altri dati utili e particolari propri dei clienti (se avrete la compiacenza di farmi sapere  ), l'indirizzo completo finirà nella tabella anazie col suo codice particolare e univoco collegato ad anacli con idcli e attraverso idsed sapremo che quello lì è l'indirizzo della sede centrale, poi la maschera registrerà gli altri indirizzi completi del magazzino e dei cantieri con lo stesso sistema.
Ogni registrazione avrà il collegamento con impiegati e addetti, telefoni e fax particolari, banche, valute.
Cosa ne dici, dite? Dovrebbe funzionare.

Se hai, avete, tempo di controllare le tabelle clienti, fornitori ecc. e dirmi quali campi mancano e/o sono errati...

[Berserker79]

Ciao Gianluigi, veramente io preferivo lo schema "Relazioni Aziende 2".
Lo schema "RelazioniAziende(20-01)" proprio non mi convince.

Ti espongo qualche idea e poi decidi cosa ti può andare bene e cosa no.

1) la tabella anazie per me dovrebbe contenere solo i dati fiscali di un nostro cliente/fornitore/nostra azienda da utilizzare per l'emissione dei documenti fiscali e per la contabilità. Il tipo di rapporto è di tipo uno (azienda) a molti (clienti,fornitori,vettori).

2) la tabella anacli conterrà i dati specifici del cliente, come indirizzo di consegna (principale), tipologia di cliente, tipo di listino ecc.

3) se il cliente ha diversi punti di consegna, potremmo inserire nella tbl anacli, un campo che indica se è "multiconsegna" (passami il termine) ed inserire nella tabella ansedi tutte le varie sedi secondarie. ad ogni sede, si potrebbe anche abbinare uno specifico vettore.

Questi sono i punti principali che vorrei che fissassimo per poter proseguire.
Ciao.

[sotema]

Ciao Gianluigi,
spiacente, ma concordo con Berseker79; da come hai disegnato le relazioni in  "RelazioniAziende(20-01)", sembrerebbe che un potenziale cliente possa avere più ragioni sociali, cosa praticamente impossibile. Mentre è possibile che un Cliente abbia diverse sedi. Ne consegue che la relazione deve essere, come detto da Berseker79, uno (anazie) a molti (anacli, anafor, anavet).

Io mi spingerei anche oltre inserendo nella tabella anazie i soli dati fiscali del cliente, rasaz, cofaz, pivaz e webaz, malaz (di solito tutte le aziende hanno una mail generica del tipo info@nomeazienda.dominio); nella tabella anacli inserirei i campi codcli (codice cliente), idazie per la relazione con anazie e il campo idsed come relazione alla tabella ansedi, il campo per identificare il listino associato (idlist?). La tabella ansedi conterrà i campi della sede: indirizzo, comune, cap, provincia, nazione, telefono, fax... ed un campo boolean, impostato a true se si tratta della sede legale. La tabella anaper, tramite i campo idsed e idazie farà il collegamento tra le persone, la sede e l'azienda.
Identico ragionamento per i fornitori.
 

[Gianluigi]

Sembrerebbe la fiera degli equivoci, io ho inserito nella tabella di supporto anazie la ragione sociale perché avevo capito che i magazzini, i negozi, i cantieri ne avessero una propria anche se dipendenti da un'unica sede. Se così non è basta togliere tutti i campi che non servono alla tabella di supporto e spostarli nella tabella delle sedi (anacli per i clienti) quelle col lato uno della correlazione.
Mi riferisco all'ultimo diagramma RelazioniAziende(20-01).

A cosa servono tre tabelle se sono sufficienti due?

Siete certi che le vostre idee sulle relazioni siano corrette? 

  

[sotema]

Una impresa detiene una ed una sola Ragione Sociale. Indipendentemente dal numero di Sedi, il termine corretto è Unità Locali, che verranno utilizzate per l'esercizio dello Scopo Sociale. La Ragione Sociale viene depositata presso la Camera di Commercio (CCIAA) della provincia dove risiede la Sede Legale; la sede legale può essere una Unità Locale dell'impresa ma anche uno Studio Legale, Studio Commercialista, residenza del Titolare o del Rappresentante Legale.  All'atto della registrazione dell'impresa viene assegnato un Numero di Partita Iva ed un Codice Fiscale (nel caso di Società di Persone o Società di Capitali spesso PIVA e CF coincidono). Ogni Sede viene poi identificata con un proprio Numero di Repertorio Amministrativo (il famoso REA).

Tre tabelle servono per tenere separati i Clienti dai Fornitori e per evitare campi nella tabella anazie, che sarebbero molto spesso impostati a NULL.  Immagina un SELECT * FROM anacli WHERE prvcli = 'RM' che ti riportasse anche i fornitori. Inoltre ti semplifica la gestione deglimordini dei clienti, la gestione dei preventivi e la gestione delle commesse.

[Gianluigi]

SELECT *
FROM anazie
WHERE proaz = "RM" AND "nuovo campo utile a sapere che si tratta di un cliente messo automaticamente dal programma e che mi ero scordato" = "cliente"

OK hai ragione è uno schifo e qui si dimostra che Hernandez a ragione quando dice “niente dati mischiati ma ben separati” ma allora potremmo sfruttare l'eredità facciamo una tabella sedgen e la facciamo ereditare alle quattro tabelle e lasciamo lo schema come da me fatto senza i campi inutili.
Non serve una terza tabella ansedi 

 

PS: sedgen la faccio solo perché sono pigro e mi voglio risparmiare la scrittura quadrupla 

PS2: Scusate ma sono fuso (oggi giornata campale lato lavoro) vado a nanna, buonanotte a tutti 

[sotema]

Buonanotte.
Per quando ti svegli ho preparato un semplice schema per illustrarti il mio punto di vista. Perdona se non ho utilizzato i nomi tabella/campi concordati, ma l'ho preparato al volo.
La tabella Clienti eredita la tabella Aziende e tramite la tabella sedi crea una relazione molti-a-molti con la tabella persone.

[Gianluigi]

Buongiorno.
Caro Sotema,
ieri hai approfittato spudoratamente della mia stanchezza, della mia non più elastica mente e della molta ruggine su quel poco che sapevo di SQL. Mi spieghi come pretendi di interrogare una sola tabella se i dati completi ce l'hai su due?   

Lo schema da me allegato (RelazioniAziende(20-01)) funziona benissimo così come l'avevo postato e lo puoi interrogare come ti pare. 

A seguire alcuni esempi che non ho provato su PostgreSQL:

Codice: [Seleziona]

SELECT *
FROM anazie, anacli
WHERE anazie.idcli = anacli.idcli
AND anazie.proaz = 'RM'

Oppure:

Codice: [Seleziona]

SELECT *
FROM anazie
INNER JOIN anacli
ON anazie.idcli = anacli.idcli
WHERE anazie.proaz = 'RM'

Se ti basta quello che c'è in anazie:

Codice: [Seleziona]

SELECT *
FROM anazie
WHERE anazie.proaz = 'RM'
AND idcli IS NOT NULL

Se desideri solo alcune informazioni:

Codice: [Seleziona]

SELECT rasaz, indaz,telaz
FROM anazie
INNER JOIN anacli
ON anazie.idcli = anacli.idcli
WHERE anazie.proaz = 'RM'

Se desideri avere il telefono dei contatti dei clienti di Roma:

Codice: [Seleziona]

SELECT anazie.rasaz,anazie. indaz, anaper.cogpe, anaper.telpe
FROM (anazie
INNER JOIN anacli
ON anazie.idcli = anacli.idcli)
INNER JOIN anaper
ON anaper.idazi= anazie.idazi
WHERE anazie.proaz = 'RM'

Oppure:

Codice: [Seleziona]

SELECT anazie.rasaz,anazie. indaz, anaper.cogpe, anaper.telpe
FROM anazie, anaper, anacli
WHERE anazie.idcli = anacli.idcli
AND anazie.idazi = anaper.idazi
AND anazie.proaz = 'RM'

Non saranno il massimo della raffinatezza ma dimostrano la robustezza del progetto. 

Ho scaricato il tuo esempio, sono molto lento nell'uso di PostgreSQL ma giuro che con calma me lo studio, così a prima vista direi che è molto simile al mio con cambio di nomi.
Non conosco l'eredità ma vedo che tu fai ereditare campi di una tabella che vanno ad aggiungersi ad un'altra (figlia) come mi pareva logico che fosse e devo lamentare che tu non hai mai risposto alle mie domande in merito. Anzi all'inizio mi avevi addirittura fuorviato 

Appena riesco ad interrogare il tuo database oppure appena non riesco a nulla ti faccio sapere. 

  

PS. Scusa mi era rimasto l'ultimo And fuori dal codice

[Gianluigi]

Ciao Sotema,
sono bloccato, ho trovato un'incongruenza fra la tabella clienti e la tabella sedi.
La tabella sedi ha come chiave primaria idsede come può essere anche chiave esterna lato molti per la tabella clienti? 

 

[sotema]

Ciao Sotema,
sono bloccato, ho trovato un'incongruenza fra la tabella clienti e la tabella sedi.
La tabella sedi ha come chiave primaria idsede come può essere anche chiave esterna lato molti per la tabella clienti? 

 

Dove sta il problema?
La chiave esterna per la tabella clienti è un vincolo referenziale; ti vieta di assegnare per un Cliente una Sede che non esiste nella tabella Sedi. Se poi volessi cancellare un Cliente (cosa per altro da evitare quasi sempre) ti permette di cancellarne in automatico (ON DELETE CASCADE) anche tutte le sedi corrispondenti.