Printable View
Sarà sicuro una cazzata, ma io odio i db e farli mi sta ancora più sul cazzo, ma chi mi paga vuole sta cosa quindi gg
Ho una entità, che chiameremo per comodità "FARMACO" con 2 attributi (Regime e Tipologia)
Ora questi 2 attributi devono per forza diventare entità, quindi ognuno di loro avrà una relazione (0,n) con l'entità FARMACO
Possibile gestirle con una unica relazione tripla(in foto sotto)?????????????
Grazie
http://s2.postimage.org/ymkpnh8tw/Immagine.jpg
E' pure ora che te lo guadagni sto stipendio eh
Tabelle di censimento, tutte con solo ID, DESCRIZIONE (se ti serve la desc):
FARMACO, REGIME, TIPO
Tabelle di relazione, con ID_FARMACO e ID_<ALTRO>:
RELAZIONE_FARMACO_TIPO, RELAZIONE_FARMACO_REGIME
Non ho capito un cazzo del disegno che hai fatto, ma questa è la prima cosa che mi viene in mente (in base a quello che ho capito) perdendoci solo 30 secondi visto che sono appena arrivato dal lavoro.
Ma quindi per forza 2 tabelle di relazione? 1 con REGIME e 1 con TIPO?Quote:
Originally Posted by Tanek
Non posso unire le 2 tabelle di relazione in una unica?
Sì certo, se la vuoi a tre ne fai una con i tre id, che sarebbero ovviamente una PK, ed eventualmente una desc per ogni terna.
(sicuro che regime e tipo non siano correlati tra loro?)
semi ot
ma come sei riuscito a farti assumere?
fine semi ot
Nessuna correlazione tra di loroQuote:
Originally Posted by Tanek
Ma poi nel momento in cui creo le 3 tabelle, la relazione non avendo attributi posso anche non crearla giusto?
sanità pubblica + alemannoQuote:
Originally Posted by Shagaz
Gia so con chi dovrò prendermela quando mancherà un farmaco in ospedale mentre sono ricoverato
Sei bravissimo a disegnare.
soprattutto.... ma che calligrafia..
va beh è fatto co paint
spero
Certo che è fatto con paint -.-
il DB?Quote:
Originally Posted by Warbarbie
buahhaQuote:
Originally Posted by oMG
Non ho capito.Quote:
Originally Posted by Warbarbie
Se non crei la tabella di relazione come diamine le metti in relazione?
Eventualmente può esistere solo quella se i singoli elementi non hanno altri attributi.
Ti proporrò come mod anche di questa sezione al posto di Hador.Quote:
Originally Posted by Tanek
Faccio un esempio
FARMACO = PERSONA
TIPO_FARMACO = SESSO
REGIME_FARMACO = PESO
in una normale situazione io modellerei solo una identita(persona) e sesso e peso sarebbero semplici attributi
Ora necessito che sesso e peso diventino invece 2 identità oltre a persona.
Può esserci una relazione a 3 tra di loro?
Persona avrebbe una cardinalità 1,1 con entrambe, quindi avremme come chiave la concatenazione della sua piu le altre 2 dalle altre identità?
a me i db fanno merda :sneer:
Sei proprio come ti descrivonoQuote:
Originally Posted by Hador
:(
cmq mi pare giusta l'ultima cosa che hai detto, anche se comunque è una porcata, però per i db devi chiedere agli altri.
Perchè è una porcata?
E se sesso e peso non fossero fissi e quindi avessi bisogno di gestirne anche eventuali cambiamenti senza impattare la tabella persona che ha qualche milione di record?(che poi è il mio caso per questo devo separare)
Ammesso abbia capito correttamente quello che vuoi, trovo molto inefficiente mettere sotto un'unica relazione 3 entita`di cui 2 (regime e tipologia) sono relazionate (0,n).
In generale, personalmente preferirei avere 2 relazioni distinte farmaco-regime e farmaco-tipologia ed eventualmente lasciare poi ad un join la possibilita` di fare l'unione delle due (magari prefiltrando, e quindi eliminando una buona fetta di calcoli). Questo per avere, nel caso pessimo, solo
E.n + E.m = E.(n+m)tuple
invece di
E.n.m tuple,
posto
E = numero istanze di farmaci
n = numero istanze di regimi
m = numero istanze di tipologie.
Poi ovviamente dipende dal contesto (in particolar modo dalla cardinalita` di farmaci, regimi e tipologie) e da quello che il cliente chiede.
ah spe tu vuoi usare come chiave primaria la tripla però... l'importante è che tu non usi solo la persona, altrimenti con le modifiche a catena rischi di buttare tutto in merda
Ok le modellerò con 2 relazioni distinte e nella tabella farmaco oltre il codice univoco chiave le 2 foreign key di tipo e regime
Grazie!!!
Cioè era diversi ordini di grandezza più semplice rispetto a quello che sembrava dovessi fare. -.-
E' ovvio che se hai una tabella con degli attributi e vuoi censirne le casistiche (esempio tuo: SESSO: M / F ) devi farne una tabella di censimento e poi usare la primary key sulla tabella padre (creando una foreign key). -.-
Beh ma il mio poblema infatti era solo se gestirla con 2 associazioni fosse migliore o no della gestione con una associazione triplaQuote:
Originally Posted by Tanek
una relazione ternaria :O ...
Metti giu' le specifiche del DB, gran pacco che non sei altro :gha: