Jag har problem med hur jag skall rita upp följande relation.
Jag har två olika kundtyper som båda har lite gemensamt... De har tex båda epostadresser (flera stycken)
Jag har skapat följande tabeller:
kundtyp1
===============
id_kundtyp1
_________________
namn
...
Kundtyp2
===============
id_kundtyp2
_________________
namn
...
epostadresser
===============
id_epost
_________________
adress
losenord
Ok... problemet jag har ser kanske inte riktigt ut som ovan men principen är densamma. Alltså: Båda kundtyperna kan ha flera epostadresser varpå det naturliga är att skapa 1:n relationer mellan kundtyp1 och epostadresser samt mellan kundtyp2 och epostadresser. Men då får jag ju två kolumner i epostadresser med kund_id där det egentligen bara behövs en kolumn med kundnummer...
Hmmm, i en E/R-Modell så har man inga ID:n med alls.
Iallfall har så jag lärt mig det. I en E/R modell behöver man inte alls se de tekniska detaljerna hur tabellerna är kopplade bara det att dom är kopplade.
Frågan är ju om du inte kan koppla samman Kundtyp 1 och kundtyp 2. Och sedan bryta det som skiljer sig åt i 2 olika tabeller kundtyp1 och kundtyp2.
Ex
Customers
Name
Osv vad som är generellt för en kunde
CustType1
vad som är generellt för CustType1
CustType2
Vad som är generellt för CustType2
Sedan mellan Kund och vilken typ dom är
Så har du en relationstabell för varje Typ
IdxCT1 (Nu lägger jag in Id:n här för att du skall förstå om man hade målat upp det som en er modell hade du bara haft ett relationsnamn)
C_Id (CustommerId som finns i Customers)'
CT1_Id (Id som finns i CustType1)
Och sedan en likadan för CustType2.
Fast om du vill så kan du skippa dessa relationsindex och använda forgin key (Med andra ord du lägger in Custommer id:t som ett extra fält i t.ex. CustType1).
Nu kan du använda Custommer Id:t för att hämta ut epost adresser utan problem :)
Jag är inne på samma spår som ni är...
I C++ kallas detta för generalisering. Alltså...
Man har en övergripande tabell som vi kallar för kund denna har relationer till typ1 och typ2. Den har dessutom en 1:n relation till epostadresser.
Men hur ser då relationerna mellan kund och typ1 och kund och typ2 ut? Hur jag än gör kommer jag att ha tomma fällt i kund isf... För antingen är det typ1 eller typ2... inte båda...
Varför måste du separera kundtyperna i två olika tabeller? Identifiera först kundtypen med en integer-kolumn i t.ex. Costumer, som heter nåt i stil med CostumerType och som är kopplad till en relationstabell, och ha alla kundspecifika kolumner (generella eller ej) i kundtabellen, med skillnad att du lämnar nullvärden i de kolumner som inte är behövda för de användarna.
Det kan ju ge lite limbo-data, men det får man ju se till att undvika i programmeringen.
Ok... det blir lite rörigt med bara text så jag hoppas att alla tycker det är ok att jag bifogar en liten bild som jag konstruerat i DBdesigner.
första bilden:
=================
Här har vi själva problematiken. Det blir ju lite overhead då ett av fälten typ1 och typ2 i epostadresser alltid kommer att lämnas tomt.
Andra bilden:
=================
Den här är nog inte riktigt färdiguttänkt... Känns halvfärdig och genererar minst lika mycket overhead?
Tredje bilden:
=================
I DBdesigner finns en relation som heter "generalisation" som jag använder (pilrelationerna). Det skumma är hur programmet väljer att lösa relationen mellan "typ2" och "dator". Jag kan ju härleda "abonnemang" genom "typ2" utan att ha med den som främmande nyckel i "dator".
Vilket är mest "rätt"?
Varför får jag den konstiga lösningen i "dator"?
Varför måste du separera kundtyperna i två olika tabeller? Identifiera först kundtypen med en integer-kolumn i t.ex. Costumer, som heter nåt i stil med CostumerType och som är kopplad till en relationstabell, och ha alla kundspecifika kolumner (generella eller ej) i kundtabellen, med skillnad att du lämnar nullvärden i de kolumner som inte är behövda för de användarna.
Det kan ju ge lite limbo-data, men det får man ju se till att undvika i programmeringen.
Eller har jag missat något?
Massor med overhead!
Det kommer att vimla av kolumner i customertabellen som inte har värden... det är rätt mycket som skiljer de olika typerna åt...
Hmmm, i en E/R-Modell så har man inga ID:n med alls.
Iallfall har så jag lärt mig det. I en E/R modell behöver man inte alls se de tekniska detaljerna hur tabellerna är kopplade bara det att dom är kopplade.
Frågan är ju om du inte kan koppla samman Kundtyp 1 och kundtyp 2. Och sedan bryta det som skiljer sig åt i 2 olika tabeller ...
Låter som det jag vill åstadkomma... dock är jag osäker på hur man ritar upp det rent "ER-mässigt"
En liten skiss?
135 ms totalt · 3 externa anrop · v20260731065814-full.4bcf49fe
