Questa domanda mostra che non comprendi appieno le relazioni tra entità (nessuna maleducazione intesa). Di cui ci sono quattro tipi (tecnicamente solo 3) di seguito:
One to One One to Many Many to One Many to Many
Uno a uno (1:1): In questo caso una tabella è stata suddivisa in due parti ai fini del rispetto della normalizzazione, o più solitamente del principio aperto chiuso.
Normalizzazione conformità:potresti avere una regola aziendale secondo cui ogni cliente ha un solo account. Tecnicamente, in questo caso potresti dire che cliente e account potrebbero trovarsi tutti nella stessa tabella, ma questo infrange le regole della normalizzazione, quindi li dividi e fai un 1:1.
Principio di apertura-chiusura conformità:una tabella cliente, potrebbe avere ID, nome e cognome e indirizzo. Più tardi qualcuno decide di aggiungere una data di nascita e con essa la possibilità di calcolare l'età insieme a una serie di altri campi molto necessari. Questo è un esempio semplificato di uno a uno, ma l'uso principale è quello di estendere il database senza interrompere il codice esistente. Gran parte del codice scritto (purtroppo) è strettamente accoppiato al database, quindi i cambiamenti nella struttura di una tabella interromperanno il codice. L'aggiunta di un rapporto 1:1 come questo estenderà la tabella per soddisfare i nuovi requisiti senza modificare l'originale, consentendo così al vecchio codice di continuare a funzionare normalmente e al nuovo codice di utilizzare le nuove funzionalità db.
Lo svantaggio della normalizzazione e dell'estensione delle tabelle che utilizzano relazioni 1:1 in questo modo sono le prestazioni. Spesso su sistemi molto utilizzati, il primo obiettivo per aumentare le prestazioni del database è denormalizzare e combinare tali tabelle in un'unica tabella e ottimizzare gli indici eliminando così la necessità di utilizzare join e leggere da più tabelle. La normalizzazione/denormalizzazione non è né un bene né un male, in quanto dipende dalle esigenze del sistema. La maggior parte dei sistemi di solito inizia a tornare normalizzata quando necessario, ma questa modifica deve essere eseguita con molta attenzione come accennato, se il codice è strettamente accoppiato alla struttura del DB, quasi sicuramente causerà il fallimento del sistema. cioè quando combini 2 tabelle, una cessa di esistere, tutto il codice che include quella tabella ora inesistente fallisce fino a quando non viene modificato (in termini di db, immagina di collegare relazioni a una qualsiasi delle tabelle in 1:1, quando rimuovi quelle tabelle , questo interrompe le relazioni, e quindi la struttura deve essere notevolmente modificata per compensare. Sfortunatamente, progetti così cattivi sono molto più facili da individuare nel mondo DB che nel mondo del software nella maggior parte dei casi e di solito non si nota che qualcosa è andato storto nel codice fino a quando tutto va in pezzi) a meno che il sistema non sia stato progettato correttamente con separazione delle preoccupazioni in mente.
È la cosa più vicina all'ereditarietà nella programmazione orientata agli oggetti. Ma non è proprio la stessa cosa.
Uno a molti (1:M) / Molti a uno (M:1): Queste due relazioni (quindi perché 4 diventano 3), sono i tipi di relazione più popolari. Sono entrambi lo stesso tipo di relazione, l'unica cosa che cambia è il tuo punto di vista. Un esempio Un cliente ha molti numeri di telefono o, in alternativa, molti numeri di telefono possono appartenere a un cliente.
Nella programmazione orientata agli oggetti questo sarebbe considerato composizione. Non è un'eredità, ma stai dicendo che un oggetto è composto da molte parti. Questo è solitamente rappresentato con array/liste/collezioni ecc. all'interno delle classi invece di una struttura di ereditarietà.
Da molti a molti (M:M): Questo tipo di rapporto con la tecnologia attuale è impossibile. Per questo motivo è necessario scomporlo in due relazioni uno a molti con una tabella di "associazione" che le unisce. Il lato molti delle due relazioni da uno a molti è sempre nella tabella di associazione/collegamento.
Per il tuo esempio, la persona che ha detto che hai bisogno di molti a molti ha ragione. Perché un due a molti è effettivamente un rapporto molti (che significa più di uno) a molti. Questo è l'unico modo per far funzionare il tuo sistema. A meno che tu non intenda effettuare ricerche nel campo del calcolo relazionale per trovare un nuovo tipo di relazione che lo permetta.
Anche per tali relazioni (m2m) hai due scelte, o creare una chiave composta nella tabella del linker in modo che la combinazione di campi diventi una voce univoca (se sei interessato all'ottimizzazione del db questa è la scelta più lenta, ma occupa meno spazio). In alternativa, crei un terzo campo con una colonna id generata automaticamente e la rendi la chiave primaria (per l'ottimizzazione del db, questa è la scelta più veloce, ma occupa più spazio).
Nel tuo esempio in particolare sopra...
Questa sarebbe una relazione da molti a molti con la tabella dei numeri di telefono come tabella di collegamento tra aziende e utenti. Come spiegato, per assicurarti che nessun numero di telefono venga ripetuto, devi semplicemente impostarlo come chiave primaria o utilizzare un'altra chiave primaria e impostare il campo del numero di telefono su univoco.
Per questo tipo di domande, dipende davvero da come le esprimi. Ciò che ti sta facendo confondere su questo e come superare questa confusione per vedere la soluzione è semplice. Riformula il problema come segue. Inizia chiedendo se è uno a uno, se la risposta è no, vai avanti. La prossima domanda è uno a molti, se la risposta è non andare avanti. L'unica altra opzione rimasta è molti a molti. Fai attenzione però, assicurati di aver considerato attentamente le prime 2 domande prima di andare avanti. Molte persone inesperte di database spesso complicano i problemi definendo uno a molti quanti molti a molti. Ancora una volta, il tipo di relazione di gran lunga più popolare è uno a molti (direi il 90%) con molti a molti e uno a uno che divide rispettivamente il restante 10% 7/3. Ma queste cifre sono solo il mio punto di vista personale, quindi non citarle come statistiche standard del settore. Il mio punto è di essere più sicuro che non sia sicuramente uno a molti prima di scegliere molti a molti. Ne vale la pena.
Quindi ora per trovare la tabella del linker tra i due, decidi quali sono le tue tabelle principali e quali campi devono essere condivisi tra di loro. In questo caso, sia la tabella aziendale che quella utente devono condividere il telefono. Quindi devi creare una nuova tabella telefonica come linker.
L'allarme di incomprensione dovrebbe apparire non appena decidi che nessuno dei 3 sta funzionando per te. Questo dovrebbe essere sufficiente per dirti che semplicemente non stai formulando correttamente la domanda sulla relazione. Migliorerai con il passare del tempo, ma è un'abilità essenziale e dovrebbe essere padroneggiata il prima possibile per la tua salute.
Ovviamente potresti anche andare a un database orientato agli oggetti che consentirà una serie di altre relazioni chiamate relazioni "gerarchiche". È fantastico se stai pensando di diventare anche tu un programmatore. Ma non lo consiglierei perché ti farà male la testa quando inizi a trovare modi per combinare i vari tipi di relazioni. Soprattutto considerando che non c'è molto bisogno poiché quasi tutti i database nel mondo sono costituiti solo da quei 3 tipi di relazioni a meno che non siano qualcosa di super duper speciale.
Spero che questa sia stata una risposta ragionevole. Grazie per aver dedicato del tempo a leggerlo.
