1 / 28

(Data)Modellering

Database Systems , Connolly & Begg third edition: kapitel 11, 12 & 14 fourth edition: kapitel 11, 12 & 15 . (Data)Modellering. nikos dimitrakas nikos@dsv.su.se 08-162099 rum 6626. Definitioner av “modell”: Robert A. Maksimchuk, Eric J. Naiburg (UML):

chantal
Download Presentation

(Data)Modellering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Database Systems, Connolly & Begg third edition: kapitel 11, 12 & 14 fourth edition: kapitel 11, 12 & 15 (Data)Modellering nikos dimitrakas nikos@dsv.su.se 08-162099 rum 6626

  2. Definitioner av “modell”: Robert A. Maksimchuk, Eric J. Naiburg (UML): A miniature representation of an object. A pattern on which something not yet produced will be based. A design or type. One serving as an example to be emulated or imitated. Wordnet: Representation of something (sometimes on a smaller scale). A simplified description of a complex entity or process. Vad är en modell?

  3. Datamodellering Modellera data som berör verksamheten. TechTarget: Data modeling is the analysis of data objects that are used in a business or other context and the identification of the relationships among these data objects. Processmodellering Modellera verksamhetens processer. Verksamhetsmodellering Modellera olika aspekter av en verksamhet. Kan inkludera datamodellering och processmodellering. Typer av modellering

  4. Konceptuell modellering oberoende av alla fysiska aspekter Logisk databasmodellering plattformsoberoende, men anpassad för vald databastyp Fysisk databasmodellering implementationsspecifik Datamodellering

  5. Faktorer som bör ingå i en modelleringsmetod: användarmedverkan. utgå endast från informationskrav. beakta integritetskrav. normalisera och validera de framtagna modellerna. använd grafisk notation så långt som möjligt, men komplettera med textuell notation när nödvändigt. använd samma metod under hela modelleringsfasen. var villig att göra om steg. Modelleringsmetod

  6. Konceptuell modellering Ta fram en konceptuell modell Logisk databasmodellering Omvandla en konceptuell modell till en logisk databasmodell Fysisk databasmodellering Omvandla en logisk databasmodell till en fysisk databasmodell Modelleringsmetod

  7. Olika notationer ER UML MOLOC ??? Olika begrepp Entiteter, klasser, koncept, begrepp Relationer, samband, associationer Attribut, egenskaper, properties Identifierare, avbildningsregler, kardinalitet, multiplicitet Supertyp, superklass, subtyp, subklass, arv Konceptuell modellering

  8. Betrakta följande exempel: En familj kan äga en bil. Varje bil ägs av en familj. Konceptuell modell

  9. Modell vs. värden/objekt Modellnivå Instansnivå

  10. Beskriver en företeelse av vilken det finns många förekomster. T ex Bil, Familj, Företag, Hund, Köp. Representeras i modellen oftast som rektanglar: Varje förekomst är ett identifierbart objekt (instans) av denna klass (entitetstyp) Klass/Entitetstyp

  11. Varje klass namnges oftast så att den beskriver vad en förekomst (ett objekt) är. Man använder oftast substantiv. T ex är ett objekt av klassen Bil en bil. Entitetstyper som är oberoende av andra kallas strong entity types Entitetstyper som är beroende av andra kallas weak entity types Klass/Entitetstyp

  12. Beskriver ett samband som kan existera mellan objekt av klasser (entitetstyper). T ex att familjer kan äga bilar eller att företag kan samarbeta med andra företag. Representeras i modellen som en linje mellan de relaterade klasserna: Relationstyp/Association

  13. Varje relationstyp har ett namn som beskriver innebörden av relationen. Namnet kan vara ett verb så att man lätt kan läsa t ex Familj äger Bil Om sambandet är mellan tre eller fler entitetstyper brukar man skapa en ny entitetstyp för sambandet med en gång. För varje relation måste man definiera följande avbildningsregler för varje sida: minimum antal objekt som måste relateras för denna relation maximum antal objekt som kan relateras Relationstyp/Association

  14. Beskriver en egenskap som en klass har. T ex kan en bil ha egenskaper som färg, märke, antal dörrar och registreringsnummer. Varje attribut måste ha en domän (värdeförråd) och följande avbildningsregler: minimum antal värden som ett objekt måste ha för denna egenskap maximum antal värden som ett objekt kan ha för denna egenskap om två objekt av samma klass får ha samma värde för denna egenskap Attribut/Egenskap

  15. Representeras i modellen oftast i klassens rektangel tillsammans med sina avbildningsregler: Attribut/Egenskap Jämför attribut och relationstyp!

  16. Sammansatt attribut (composite attribute) T ex adress som består av gatuadress, postnummer och postort. Härledbart attribut (derived attribute) T ex antal bilar som en familj har. Flervärt attribut Ett objekt har flera värden för detta attribut Attribut/Egenskap

  17. Varje objekt måste kunna identifieras unikt. Alla objekt som tillhör samma klass (entitetstyp) måste identifieras på samma sätt, dvs med hjälp av samma attribut och relationer. Varje klass identifieras av en samling envärda attribut och relationer. Varje klass kan identifieras av flera olika kombinationer attribut och relationer. Identifierare

  18. Kallas också Business rules eller Enterprise constraints Regler som ingår i verksamheten men kan inte visas grafiskt i modellen (oftast pga att de är beroende av objektens värden). Är en del av modellen och kompletterar den grafiska delen. T ex att en familj på 5 eller flera personer inte får äga en röd bil. en anställd på ett företag får inte ha högre lön än sin chef. Verksamhetsregler

  19. Ett-till-ett (1:1) T ex: En person äger en hund och en hund ägs av en person. Ett-till-många (1:M) T ex: En familj äger flera bilar och varje bil ägs av en familj. Många-till-många (M:M) T ex: Ett företag säljer många produkter och varje produkt säljs av många företag. Obs! Endast maximum (kardinalitet) anges i denna uppdelning Relationstyper

  20. Superklass Den generella klassen i arvshierarkin Subklass Den specifika klassen i arvshierarkin Exempel: Superklass: Person Subklass: Lärare Representeras oftast enligt följande notation: Kan läsas Lärare is a (är en) Person Arv

  21. Attribut och relationer som finns för superklassen ärvs ner till alla subklasser. Andra regler som bör beaktas: Måste alla objekt av en superklass tillhöra även en subklass? (Participation constraint) Får ett objekt tillhöra flera subklasser? (Överlappande subklasser) (Disjoint constraint) Arv

  22. Arv

  23. Identifiera klasser Definiera namn Identifiera relationer Definiera namn Definiera multiplicitet Identifiera attribut Definiera namn Definiera domän Definiera multiplicitet Identifiera identifierare Identifiera verksamhetsregler Konceptuell modellering

  24. Modellera följande verksamhet: Varje familj har ett namn och en adress. Varje familj består av flera personer. Varje person har ett namn och ett födelseår. Varje familj kan äga hundar. Varje person kan äga fiskar och hamstrar. Alla husdjur har namn och färger. Hundar har en ras. Personer har olika ansvar i hemmet (t ex diska, tvätta). Samma arbetsuppgift kan dock delas av många. Om en person äger två eller flera fiskar får denna person inte äga hamstrar. Exempel

  25. Identifiera klasser Definiera namn Exempel

  26. Identifiera relationer Definiera namn Definiera multiplicitet Exempel

  27. Identifiera attribut Definiera namn Definiera domän Definiera multiplicitet Exempel

  28. Identifiera identifierare Identifiera verksamhetsregler Exempel

More Related