Hej! Jag är långt ifrån en expert vad gäller att modellera databaser och har därmed stött på vissa "frågeställningar" under ett projekt jag håller på med. Jag kan lösa problemen men jag tycker inte de blir optimala och undrar om det inte finns något smartare sätt att lösa dessa problem på. Kanske det rentav finns vissa best practices jag missar.

Problem 1 - Multilevel alternativ
I min databas existerar det en entitet som skall ha en viss typ och subtyp. Entitietens subtyp är direkt kopplad till entitetens typ (parent/child förhållande). Exempel: Entiteten fordon kan antingen vara av typen: Bil, Buss, Lastbil. Bilar har subtyper som: Personbil, Van och bussar: Innerstadsbuss, lantbuss etc..
Min lösning på detta problem finns här: http://img147.imageshack.us/img147/2251/typeexample.png
En entitet har via relationer en typ och en subtyp. Subtyperna relaterar även till typerna så att man inte kan skapa föräldralösa subtyper. Problemet jag ser med denna modellen är att databasen inte automatiskt försäkrar sig om att det som matas in i entiteter följer "reglerna" för typer och dess subtyper. Det finns inget som hindrar att mata in en entitet av typ "Bil" med subtypen "Lantbuss". Detta ansvar lämnas åt programkoden. Jag skulle vilja se en lösning där relationer/constraints förhindrar denna typ av potentiella felinmatning men har inte kommit på något sätt att lösa detta. Så min fråga är om någon kan komma på ett smart sätt att lösa detta dilemma.

Problem 2 - Arv i databaser
Mitt andra "problem" jag stött på är hur man skulle kunna simulera arv i databaser. Missförstå mig rätt här. Det är inte arv i sig jag är ute efter dess "smarta" struktur. Det är så att jag har viss likartad data i en datamängd tillika data som skiljer sig beroende på vilken typ enskild data har. Ok, det där lät svårt/otydligt. Tänk dig att du har en databas med massa frukt; bananer, äpplen, päron etc. Alla dessa frukter har ett antal attribut som är lika men bananer har vissa attribut som bara gäller bananer. Hur skulle du då modellera en databas där vi har massa frukt och där vi sedan skall kunna gå in på varje enskild frukt och titta på dess unika attribut.
Här är min lösning: http://img23.imageshack.us/img23/9177/attributesexample.png
Här har vi en tabell med massa frukt. En av fruktens attribut är dess typ (FruitTypeId). Beroende på vilken frukttyp vi har kan vi gå in i respektive specifik frukttabell för att läsa av mer information. Exempel: En viss rad i Fruits har en FruitTypeId som refererar till FruitTypes->Name=Banan. Vi vet då att vi kan leta i BananaAttributes->FruitId = Fruits->Id för att få fram rätt rad i BananaAttributes. Problemet med denna lösningen är den samma som ovan. Vi lämnar över en massa ansvar till programkoden för att ta reda på rätt information tillika uppdatera/skapa rätt information. En annan lösning på detta problemet skulle kunna vara att helt skippa "arven" och bara ha olika tabeller för olika frukter men därmed går vi ifrån förmågan att dynamiskt kunna lägga till nya frukter vilket är oacceptabelt. En dröm här skulle vara att kunna ha frukt med gemensamma attribut och sedan, beroende på vilken typ av frukt få en länk in i en undertabell med specifik data om just denna frukten. Detta med hjälp av constraints som försäkrar korrekta relationer.

Tack på förhand

I problem 1 så ser jag ingen lösning på problemet med att fel typ skulle kunna matas in men smartare personer än mig kanske har en lösning på problemet.

I problem 2 så vill du inte ha olika tabeller för olika frukter eftersom du inte så fall kan lägga till dessa dynamsikt, med den lösning som du har här så kan du inte det heller. Det eftersom du har skapat tabeller för de olika attributen. ÄppelAttribut och BannanAttribut om du skall lägga till en Apelsing så måste du in och skapa en ApelsinAttribut tabell och du kan du lika gärna skapa en Apelsintabell.
Lösning blir att skipa de specifika attribut tabellerna och bara ha en attributtabel där du kommer ha typ 4 kolumner.

FruitID, AttributeName, AttributeValue och AttributeType. Då kan du (om än inte speciellt snyggt) med hjälp av kod (i .NET reflektion) plocka ut alla attributen för en Frukt och sedan använda a AttributeType för att omvandla AttributeValue till rätt typ och sedan med hjälp av reflektion och AttributName sätta detta värde till rätt property.

- M

Problem 1:

Type:
ID
Name

Subtype:
ID
TypeID
Name

Entity:
SubtypeID
Name



Problem 2:
Förutom den helt dynamiska finns en rad lösningar;
1.

Frukter:
ID
Fruktattribut
Bananattribut


2.

Frukter:
ID
Fruktattribut

Bananer:
FruktID
Bananattribut

3.

Frukter:
ID
Fruktattribut

Bananer:
FruktID
Bananattribut


3.

Frukter:
ID
Fruktattribut

Bananer:
ID
Fruktattribut
Bananattribut

4.

Frukter:
ID
Fruktattribut
BananID

Bananer:
ID
Bananattribut



Problemet är att databaser inte kan hantera trädstrukturer speciellt bra. Ingen lösning är bättre än någon anna, det beror på din situation. Något måste du hantera i kod någonstans.

Ah, yes. Du har helt rätt i det du säger att olika tabeller inte blir dynamiskt. Feltänk av mig där. I övrigt är din lösning en bra infallsvinkel och en jag faktiskt använder i andra sammanhang. Men i just detta fallet kan jag inte använda en sådan teknik då vissa attribut kommer att referera vidare till andra tabeller i databasen och då missar jag relationer/constraints på den datan tyvärr.

Problem 1:
Jag förstår inte riktigt vad du menar med den strukturen du föreslår och undrar om du kunde utveckla den lite? Jag ser att du i Entity väljer ett attribut: Name. Vad menar du att detta är kopplat till? Eller menar du att det är en okopplad kolumn? Hur menar du att din lösning löser de problem jag skriver i problemformuleringen?

Problem 2:
Du skriver att "Förutom den helt dynamiska finns en rad lösningar:" vad menar du med detta? Vad är den helt dynamiska lösningen? Jag antar att du syftar Magnus inlägg om en "allmän attributtabell"?
Jag antar att du med dina olika alternativ vill peka på de olika sätt man kan lösa problemet på men att ingen av dem löser problemet jag ställde i ursprungsfrågan? Dvs, skapa en arvstruktur i relationsform och/eller låsa tabellerna så hårt som möjligt med constraints för att säkra dataintegriteten och lyfta över ansvar från kod till databasmotorn?

<b>>Jag förstår inte riktigt vad du menar med den strukturen du föreslår och undrar om du kunde utveckla den lite? Jag ser att du i Entity väljer ett attribut: Name. Vad menar du att detta är kopplat till? Eller menar du att det är en okopplad kolumn? </b>
Jag visar bara på principen, jag låtsas att den "fria" informationen i varje tabell bara är "Name".

<b>Hur menar du att din lösning löser de problem jag skriver i problemformuleringen?</b>
Okej, jag kan ha missförstått.
<b>>I min databas existerar det en entitet som skall ha en viss typ och subtyp. Entitietens subtyp är direkt kopplad till entitetens typ (parent/child förhållande).</b>
Okej, vi kan börja med Typ och Subtyp. Typ innehåller "Bil", "Buss", osv. Varje Typ har ett antal Subtyper, varje Subtyp tillhör exakt en Typ.

Detta tolkar jag då som att en entitet alltid har en typ och en subtyp. Dvs, "Bil, Suv", "Buss, Stadsbuss". Men man kan aldrig välja bara en typ utan subtyp? Och man ska aldrig kunna välja "Bil, Stadsbuss"?

Då är lösningen att du inte alls sparar typen för entiteten. Spara bara subtypen, så får du ut typen med en join.



Problem 2:
<b>Du skriver att "Förutom den helt dynamiska finns en rad lösningar:" vad menar du med detta? Vad är den helt dynamiska lösningen? Jag antar att du syftar Magnus inlägg om en "allmän attributtabell"?</b>
Jepp.
<b>Jag antar att du med dina olika alternativ vill peka på de olika sätt man kan lösa problemet på men att ingen av dem löser problemet jag ställde i ursprungsfrågan? Dvs, skapa en arvstruktur i relationsform och/eller låsa tabellerna så hårt som möjligt med constraints för att säkra dataintegriteten och lyfta över ansvar från kod till databasmotorn?</b>
Ja, och jag var väl förmodligen otroligt otydlig, men det jag menar är att det inte _går_ att skapa en vettig arvsstruktur i relationsform.

Du har fortfarande många alternativ, men eftersom relationsmodellen och objektsmodellen mismatchar så kommer du inte få en speciellt bra lösning hur du än gör. Det är ingen större ide att försöka göra en perfekt lösning. Alla varianter har sina fördelar och nackdelar. Om du vill så går det säkert att göra en relationslösning som är mer eller mindre omöjlig att förstöra dataintegriteten på, men då är det ett helvete att jobba med istället.