Det finns några olika "lager" man använder sig av vid modellering.
- Den konceptuella nivån är själva verkligheten - ett bibliotek, en taxitjänst etc.
- Den logiska nivån är en uppsättning regler.
- Den fysiska nivån är implementationen i SQL.
En entitet är substantiv inom området.
Låt oss tänka oss en styguthyrning. Vi ser över tjänsten på en konceptuell nivå.
| Stuga |
|---|
| Yta |
| Pris |
| Adress |
| El |
| Vatten |
Ett sådant substantiv vore stuga. En stuga har bland annat egenskaperna yta, hyra, adress, åtkomst till el, åtkomst till vatten. Entiteten stuga går alltså att förse med ett antal attribut. På så vis får vi bekräftat att vi jobbar med en entitet - den har attribut.
Låt oss tänka oss en båt.
| Båt |
|---|
| Bärvikt |
| Längd |
| Typ |
En stuga bör rimligtvis inte hyras ut flera gånger till olika personer vid samma tillfälle. Vi bör på så viss hantera bokningar, vilket ger oss entiteten bokning. En bokning tillhör rimligtvis en kund.
| Kund |
|---|
| Namn |
| Ålder |
| Telefonnummer |
| Bokning |
|---|
| Stuga |
| Kund |
| Period |
| Båt |
De sammankopplingar som sker ger oss ett väldigt övergripande databassystem.
Vi ser nu över kardinaliteten på våra entiteter.
En stuga kan ha en bokning. En bokning kan ha 0 till många stugor.
En båt kan ha många bokningar. En bokning kan ha flera båtar (0-m). Problem m-m! Vi skapar entiteten BokningsRad.
En kund kan flera bokningar. En bokning kan ha en kund.
Den ideala kardinaliteten är 1-m (en till många). Vi kan inte hantera förhållande m-m (många till många).
Låt oss ha Entitet A och Entitet B. A kan ha 0-m B, B kan ha 0-m A. Vi tar bort den relationen och gör en sammankoppling EntitetAEntitetB. EntitetAEntitetB kan innehålla 0-m A och 0-m B.