Datamodeller. 1. Elementerne. Vi betragter E/R-diagrammet, som et diagram over entiteter og relationer Tegneregler: Entitet



Relaterede dokumenter
Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5

Hvad er en relationsdatabase? Odense, den 19. januar Version 1.0

Databaser. 3. Normalform. Mette Frost Nielsen

ER-modellen. Databaser, efterår Troels Andreasen. Efterår 2002

Skriftlig eksamen i kurset. Informationssystemer

Introduktion til programmering

Databaser. Område / Specialefag nr Database, design og programmering Datatekniker Infra & Prog IT-Supporter AMU Kursister

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar Forelæser: Rasmus Pagh

Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE

Indholdsfortegnelse for kapitel 3

Fra ER-Diagram til Relationel model i 7 step

Databasesystemer, forår 2006 IT Universitetet i København. Forelæsning 3: E-R modellering. 16. februar Forelæser: Rasmus Pagh

Jørgen Koch. och. Access. Normalisering m.v.

PRÆSENTATION AF ER-DIAGRAMMER OG NORMALISERING

Tema Titel Materiale 1 IS i sundheds-sektoren Patientdatas anvendelighed Lynge et al.

DATABASE - MIN MUSIKSAMLING

Informations- og datamodellering

Anvisning i aflevering af bitemporale data

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database

Database. Pr jekt. Hold CLmul-a14e Gruppe 3 3. semester Vejledere: Tue Becher Ivan R. Frederiksen

Funktionel afhængighed

Dataanalyse og databaser

Smagsprøve. Databasedesign med Access 2000

Skriftlig eksamen i. Databaser. Vinter 2002/2003

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Undervisningsbeskrivelse

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Data lagring. 2. iteration (implement backend)

! Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen.

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 4: Mere om E-R modellering. 24. februar Forelæser: Rasmus Pagh

Skriftlig eksamen i. Databaser. Vinter 2002/2003. Vejledende løsninger

DB undervisning 01-01

UC Syddanmark

Database design for begyndere

Databaseteori. 19. Databaser. 20. Kartotek eller database. 21. Database

Håndbog Til CPR services

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Eksamen, DSDS, efterår 2007

Salgsrabatter. Forudsætning for rabatter... 2 Introduktion til rabatter... 3 Kunde/Vare-rabat Kunderabat... 4 Varerabat... 8

DATABASE DESIGN. En note om database design, normalisering og database generalisering

Excel sortering-filtrering

Synkronisering af kundestamdata

Hovedopgave 2003 på datamatikerstudiet, IT Akademiet, Skive Handelsskole INDHOLDSFORTEGNELSE... 1 INDLEDNING... 4 PROBLEMFORMULERING...

Afleveringsbestemmelse for Kingo

Integration af DocuBizz og Helios

Tilretning af importdatafiler

Karens lille vejledning til Access

Introduktion til programmering

Metadata og dokumentation af ETL-processen

Matematik og dam. hvordan matematik kan give overraskende resultater om et velkendt spil. Jonas Lindstrøm Jensen

Opret ny bruger Tilknyt medlemskab Ændre Mail-adresse Ændre password.

Jørgen Koch. Access. Opgavehæfte

Manglende konsistens i datamodellen og upræcise SQLsætninger er årsagen til, at mange IT-systemer fejler.

DEN GODE MODEL: OPSAMLING PÅ MODELLERINGSOPGAVER OG INTRO TIL MODELLERINGSALTERNATIVER

Erfaringer med CPR-replikering

Indholdsfortegnelse. Systembeskrivelse kapitel 3 Forretningslogik

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade København Ø

Vejledning til upload af e-bog via web-formular på

Septimas høringssvar vedrørende dokumenteterne FKG datamodellen - Version Fysisk implementering.pdf og FKG_2_3_1_mssql.sql

Software Dokumentation

Type af fejl Eksempler på fejl Rettet til korrekt dansk sammensatte ord. lærene er flinke alarmen giver trykhed priviligeret resource indiferens

PHP Snippets. De små korte. Skrevet af Daniel Pedersen

Indholdsfortegnelse resultat- & kritikprogrammet.

! Kia Dahlen. Kamilla Klein, Pia Jensen og Maria Korshøj Andersen.

Faktaark. Konflikthåndtering

Projekt Database, Gruppe 4A. Projekt 1, 3. Semester D A T A B A S E. Klasse MulA13 Gruppenummer: A4

Regneark for begyndere

FAT test kan kun undtagelsesvis overføres, et eksempel kunne være verifikation af tag nummerering og el-diagrammer, som kræver en adskilt maskine.

Indholdsfortegnelse for kapitel 2

3. semester, 2. projekt: Database

Database for udviklere. Jan Lund Madsen PBS10107

Systemspecifikt bilag til Rakat e-handel

ABC-rapportering baseret på Variabilitetsprincippet og ERP

Håndbog Til CPR services

Datalagring og formater

5. OPSÆTNING DOKUMENTSKABELONER 5.1 TRIN

Modul 16, Word 5 Felter, tabeller og breve

I det følgende gives en vejledning af brug af orddiktaten. Først som lærer. Derefter kort om elevernes brug af orddiktaten.

Daglig brug af JitBesked 2.0

Skriftlig opgave. Designtanker i database-nære systemer

Metodehåndbog. Begrebsmodeller, Informationsmodeller og Begrebsdefinitioner. Udarbejdet i fællesskab mellem Udbetaling Danmark/KL/KOMBIT

Jayne Alice Jensen [Link til portfolio]

Objects First with Java A Practical Introduction Using BlueJ

Transkript:

Datamodeller I forlængelse af noten om normalisering, følges der her op med redskabet E/R-diagrammer til opstilling af en datamodel, opfat således dette som en alternativ metode mere end endnu et redskab til datamodellering.. Elementerne Vi betragter E/R-diagrammet, som et diagram over entiteter og relationer Tegneregler: Entitet En rektangulær kasse symboliserer en entitet (entiteter bliver til tabeller) Relation En diamant (eller en rude) symboliserer en relation mellem to eller flere entiteter. (kan nogle gange blive til en tabel) Et E/R-diagram er en logisk eller begrebsmæssig tegning af lagrede data. Dette kaldes også en datamodel. Senere kan datamodellen gøres fysisk eller implementeres i form af en database, efter nogle retningslinjer, som beskrives herunder i Ordredatamodellen: KUDE Har afgivet ORDRE omfatter VARE Side: af 7

Fordelen ved at starte med en model eller en arkitekttegning er velkendte fra andre sammenhænge: Det er en nem og billig måde at udføre eksperimenter med løsningsalternativer Det giver overblik og mulighed for at tale sammen om det endelige produkt på en konstruktiv måde Det bidrager med en arbejdstegning, der kan bruges ved fremstilling af det endelige produkt dét, der også kaldes at implementere. Det gør at man efter implementeringen har en udmærket dokumentation til produktet. 2. Relationer En relation er en forbindelse eller en sammenhæng mellem entiteter. I ordredatamodellen ovenfor er der to relationer Kunde har afgivet ordre og Ordre omfatter vare. Relationerne kan også læses den anden vej, så skulle de have heddet ordre er afgivet af kunde og Vare er omfattet af ordre. Relationstyper Relationstypen angiver hvor mange entiteter relationen forbinder; man skelner mellem rekursive ( entitet), binære (2 entiteter) og tertiære (3 entiteter) relationer. Rekursive relationer forbinder således en entitet med sig selv: Hund er hvalp af Binære relationer forbinder to entiteter. Det er klart den mest almindelige relationstype: and er gift med Kvinde Tertiære relationer forbinder 3 entiteter: land medikament m m har licens til at sælge m i land medicinalfirma m Side: 2 af 7

Relationsgrader Relationsgraden (også kaldet kardinaliteten) er en beskrivelse af antalsforholdet mellem entitetsforekomsterne ved en relation: Relationsgraden : efører fører en Relationsgraden er : (læses: en til en ). Én efører fører højest. Og én føres højest af én efører. Læg mærke til at kardinaliteten først er tolket fuldt ud når man har prøvet fra begge sider (eksemplet dækker bedst på blind med fører eller en tolder med en narko glem alt om slædee på/i Grønland). Relationsgraden : kommer fra kennel Her ved relationsgraden : (læses: én til eller til mange ) er det lettere at se noget om læseretningen. an hiver først fat i én for at finde ud af hvor mange kennelerm den kan stamme fra så skriver man ovre ved kennel. Så tager man fat i kennel og finder ud af hvor mange e, der kan stamme fra den - så skriver man for mange ovre ved det var jo et antal e, man havde fundet frem til. Relationsgraden : har behandlet dyrlæge Dette diagram skal mht. til relationsgraden tolkes således: Relationsgraden er : (læses til eller mange til mange ). En kan have været til konsultation hos mange forskellige dyrlæger og en dyrlæge kan have haft mange forskellige e i behandling. Grunden til, at man ikke bruger begge steder, er for at tydeliggøre at der ikke nødvendigvis er tale om det samme antal e og dyrlæger i relationen. Side: 3 af 7

edlemstyper edlemstypen angiver, om entitetsforekomsterne i en entitet skal deltage i en bestemt relation. Er medlemstypen obligatorisk, skal alle entitetsforekomster deltage i relationen. Er medlemstypen frivillig, kan der godt findes en entitetsforekomst der ikke deltager i relationen. dyrlæge har behandlet Obligatorisk edlem Fed streg Vi kan godt forestille os en, der aldrig har været til dyrlæge. en det er svært at være dyrlæge uden at have behandlet flere e kunde har afgivet ordre En ordre kan ikke eksistere uden en kunde, (hvordan skal ordren ellers kunne ekspederes) - men en kunde kan godt oprettes uden afgivelse af en ordre. Eksempel: Vi reflekterer på en henvendelse hvorefter vi fremsender reklamer tilbud kataloger. Dette sker inden ordren afgives og måske fører det aldrig til en ordre men vi opretter den potentielle kunde i vores database. Hvorfor skal relationstyper, relationsgrader og medlemstyper bestemmes? Det kan virke besværligt så der skulle gerne være en god grund til, at vi gør det. For det første får man beskrevet integritetsreglerne for området meget præcist. Det er eksempelvis rart at vide, om kunder først oprettes, når de har afgivet en ordre, eller allerede på dét tidspunkt, hvor de rekvirerer et katalog. Sådan noget vil blive afklaret ved fastsættelsen af medlemstyper. For det andet skal man på et tidspunkt tage stilling til om nogle af entiteterne og relationstyperne kan reduceres. At en entitet eller en relation reduceres vil sige at den ikke bliver til en tabel i den endelige database attributterne flyttes i stedet ud i en af Side: 4 af 7

de andre tabeller. Ganske bestemte regler skal være overholdt for at man kan tillade sig at reducere: En relation kan reduceres, hvis relationstypen er rekursiv eller binær, medlemstypen er obligatorisk i mindst en af siderne, og der på den anden side står i relationsgraden (kardinaliteten). En entitet kan reduceres, hvis relationstypen er rekursiv eller binær, relationsgraden er : og medlemstypen på begge sider er obligatorisk. Hvis de nævnte regler ikke overholdes vil der opstå redundans (data, der forekommer overflødigt mange gange) eller andre dårligdomme (anomalier). 3. Attributter. Attributterne er de egenskaber ved entiteterne og relationerne, der skal gemmes dat om i tabellerne. Attributterne er med andre ord tabellernes kolonneoverskrifter. De skal bruges til at identificere og beskrive og listes i tabellerne. Tabelskitsernes form ses af figuren: Først entitetens eller relationens navn og så i parentes bagefter en liste med alle attributterne adskilt med komma. Ordredatamodellen: KUDE Har afgivet KUDE (kundenr, fornavn, efternavn, tlfnr, ) ORDRE (ordrenr, kundenr, ordredato,.) VARE (varenr, varenavn, enhedspris,.) ORDRE_OFATTER_VARE (ordrenr, varenr, antal) ORDRE omfatter VARE Side: 5 af 7

Attributterne bruges som sagt bl.a. til at identificere de enkelte rækker/forekomster i tabellen. I dén forbindelse taler man om nøgleattributter eller blot nøgler. an taler om flere forskellige slags nøgler: En kandidatnøgle er en eller flere attributter, som entydigt kan udpege rækkeforekomster i deres tabel. Der må ikke være flere attributter med end nødvendigt (Eksempel: kundenr, fornavn+efternavn og tlfnr i KUDE). En primærnøgle er den kandidatnøgle, der er blevet valgt som den vigtigste identifikation af tabellens rækker. Den markeres med en understregning i tabelskitsen (eksempel: kundenr. i KUDE). Set lidt i bakspejlet er kandidatnøglerne altså attributter eller attributkombinationer, som kan bruges som primærnøgle deraf navnet. En alternativ nøgle er en kandidatnøgle der ikke er blevet valgt som primærnøgle (eksempel: fornavn + efternavn og tlfnr i KUDE). En sammensat nøgle er en nøgle, der er sat sammen af flere attributter (eksempel: fornavn + efternavn i KUDE). En fremmednøgle er en eller flere attributter, der indeholder en værdi, der står som primærnøgle i en anden tabel eller i en anden række i samme tabel. Fremmednøgler markeres med kursiv i tabelskitserne (evt. ved stiplet understregning i håndskrevne tabelskitser). Eksempel: kundenr i ORDRE, ordrenr og varenr i VARE. Kandidatnøgler Primærnøgle Alternative nøgler x x x x x x Læg mærke til at relationerne ofte implementeres med en sammensat primærnøgle, der består af fremmednøgler, som peger på de entiteter, der indgår i relationen. Attributter kaldes i daglig tale også for felter. (I Java bliver attributter implementeret som variable ). Side: 6 af 7

Find entiteter, relationer og attributter I visse tilfælde kan det være vanskeligt at vide om man står med en entitet, en relation eller en attribut. Så kan man gribe til følgende beskrivelser af de sproglige sammenhænge: Entiteter: avneord, der beskriver noget, der kan identificeres, som der er behov for at gemme information om, som overholder et fast regelsæt, og som har et fast sæt af egenskaber. Relationer: Udsagnsord i sætninger, hvor navnet på to eller flere entiteter indgår (Studerende låner bøger). Attributter: avneord, der kan udtrykke en egenskab ved en entitet herunder: -navneord, som kan antage en værdi (vægt, pris, antal ) -sammensatte navneord, hvor første led er en entitet ( Varepris o.l.) -sammensatte navneord, hvor sidste led er id, nr, kode el.lign. -ofte kandidatnøgler RESUÉ Vi skal opfatte E/R-diagrammerne som en alternativ datamodelleringsmetode eller værktøj. Det meget anvendeligt til kommunikation med kunden, som vi vil lave databasen til. Det kræver at vi sætter kunden/brugen ind i tegnereglerne. Vi kan så afstemme virksomhedens måde at opfatte virkeligheden på med vores model. år vi har det færdige E/R-diagram (godkendt af kunden) går vi i gang med implementeringen kombineret med de reduceringer, der er beskrevet på side 4 og 5. (konkret ser vi i ordredatamodellen, hvordan relationen afgivet bliver reduceret bort ved, at primærnøglen på er-siden bliver fremmednøgle på n-siden, sagt på en anden måde kundenr bliver fremmednøgle i ORDRE dette opretholder relationen mellem de 2 entiteter KUDE og ORDRE. (Dette kunne kun lade sig gøre fordi???? obligatorisk medlemskab af ORDRE til ) år vi implementerer og reducerer efter de givne regler, får vi som hovedregel foræret en database på 3 normalform. Dette kan man dog ikke være helt sikker på. Derfor er det en god idé, at løbe normaliserings betingelserne igennem på den model man ender op med. DTU 9/0 2007 Finn Gustafsson Side: 7 af 7