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

Størrelse: px
Starte visningen fra side:

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

Transkript

1 DATABASE DESIGN En note om database design, normalisering og database generalisering Summering: Følgende note, er en indførsel i problemstillingerne for at gå fra virkelighedens problemstilling der skal designes til et database layout som en meget kort introduktion. Begreber fra den objekt-orienterede analyse introduceres. Ligeledes en introduktion til 3 typer af normalisering: Felt normalisering, Tabel normalisering, og Database normalisering. Oftest kun Tabel normalisering der undervises i på diverse undervisnings institutioner (og ofte kun til 3. normalform). Der beskrives med eksempler på tabel normalisering af 1-5 normal form inkl. Boyce-Codd normalform. I appendix diskuteres problemstillingen med definition af 1. normalform. Danny Stoltenberg Stjerne, Side 1

2 Database design af virkeligheden Model af virkeligheden Når man skal skabe en database for at lagre data for en given problemstilling er database ofte en simplificering af det problemområde som eksisterer i virkeligheden. Det som man ønsker at håndtere er ofte en række datastrukturer der er indbyrdes relatede. Det er som oftest et ønske om kun at registere en mindre delmængde af de mest relevante informationer fra den ønskede virkelighed. Man oplever dog ofte, at der opstår en kombination af bevidst valgte afgrænsninger men også ikkeopfattede væsentlige informationer når der skabes en given model jf. Nedenstående figur. Den (opfattede eller) modellerede virkelighed Den faktiske observerede virkelighed Virkeligheden som de fleste der skal skabe en model opfatter består af objekter. Hvert objekt har nogle unikke informationer der identificerer det givne objekt, og det er disse data som man ønsker at lagre i en database. Dette kan være informationer om personer, virksomheder, Produkter, begivenheder etc. For at kunne gemme informationerne fra specifikke indentificerede objekter skal man have beskrevet det som er fælles for alle objekter. Altså en klacifisering af ensartede objekter. Herom i det næste afsnit. Der findes ingen formel for hvorledes man bliver en god konstruktør af virkeligheden. Det er oftest et spørgmål om masser af erfaring, men også i høj viden om værktøjerne som vil blive beskrevet i det følgende, samt en lille smule flair. Danny Stoltenberg Stjerne, Side 2

3 Det objekt-orienterede begrebs apparat I det følgende bliver en absolut kun lille delmængde af den objekt-orienterede teori introduceret, da ideer fra dette område omvendt i høj grad kan benyttes når man skal modellere en given virkelighed og have en database beskrevet. Klasse og objekt definitioner I det forrige afsnit blev begreberne objekt og klasse introduceret. Klasse I objekt-orienteret termonologi er en klasse en beskrivelse der definerer ensartede objekter. Altså en skabelon for hvordan objekter af den givne klasse ser ud og agerer. Objekt I objekt-orienteret termonologi er et objekt en instans af et givet objekt. Med instans menes et faktisk skabt og fungerende objekt baseret på klasse skabelonen. Attribut I objekt-orienteret termonologi er et attribut en specifik karakteristik i en given klasse. En attribut kan eksempelvis være navn, farve, størrelse etc. Beskrivelsen der definerer en klasse er altså bl.a. netop en mængde attributter der beskriver klassens indhold. En attribut har en given datatype og en given indholdsmængde også kaldet domæne (definition af domæne senere). En attribut svarer til et felt i en tabel i en database. Eksempelvis kan man sige, at en arkitekttegning af et hus er en klasse af det givne hus. Det faktisk byggede hus er en instans af den givne klasse og dermed et objekt af denne arkitekttegning. Der kan oftest bygges mange forholdsvis ensartede objekter af den samme klasse, men objektets attributter såsom valg af byggestenstype, tag, farver etc. kan være forskellige fra objekt til objekt, men de tilhører stadig den samme klasse, og klassen har samme mængde attributter. Fra objekter over klasse til relations tabeller Når man i sin model af virkeligheden har identificeret et eller flere objekter som man ønsker at gemme informationer om er der som oftest tale om objektets klasse attributter. Det gælder derfor om at få analyseret objekterne og identificeret hvad der er fælles attributter som beskriver den generaliserede klasses attributter. Klassen i form af dens attributter kan mappes direkte til en tabel (eller mere korrekt benævnt: en relation Se definition nedenfor). Det gælder altså om at tænke i objekternes abstrakte klasse attributter for at få defineret hvilke karisteristika (klassens attributter) man ønsker at lagre på database niveau. Man skal ikke tænke i specifikke objekter, men i klasser og disse klassers attributter. Danny Stoltenberg Stjerne, Side 3

4 Tabeller og normaliseringstankegange Nogle database tekniske definitioner Relation Database teoretisk er en relation en uordnet mængde af relaterede attributter og en mulig mængde af uordnede tupler. En relation består derfor af en uordnet men relateret mængde af attributter og en mulig mængde af uordnede tupler (tupler: svarende til rækker i en tabel og rekords i en database). En tuple kan derfor opfattes som værende en tabels objekt, mens tabeldefinitionen kan opfattes som værende klasse beskrivelsen som definerer hvilke objekter der tilhører klassen. Med relaterede attributter menes, at hver attribut der indgår i relationen har minimum en relation til en anden attribut i relationen. Kortfattet sammenhæng mellem objekt-orienteret teori og database definition. Klasse => Tabeldefintion (relation) (mængde af relaterede attributter/felter) Objekt => Rekords i tabellen (tupler) Domæne Database teoretisk er et domæne udtryk for det udfald af værdier en given attribut kan indeholde i en relation. En attribut der hedder farve kan altså indeholde navne på farver eller farvekoder eller en anden identifikation af hver farve, og domæne begrebet er altså dels en beskrivelse af typen der identificerer farven og den mulige udfaldsmængde af værdier til attributten. En tabeldefinition i en database er derfor en implementeret beskrivelse af en relation som beskriver mængden af attributter (felter) og deres typer. De kommercielt største tilgængelige relationsdatabaser implementerer dog ikke tabel definitions begrænsninger via tabeldefinitionen på attributtens domæne da dette ikke indgår i de officielt standardiserede sprog til database manipulation (SQL). Ved at få beskrevet virkeligheden som man ønsker at modellere i den afgrænsede models klasser og de attributter som man ønsker at gemme informationer om, har man altså de nødvendige informationer til at få defineret de tabeller i databasen som skal benyttes i modellen. Integritets begrebet Man arbejder med 3 hoved integritetsområder indenfor database teori. Entitets integritet (se senere under beskrivelsen af 1. normalform), og dels referentiel integritet og dels semantisk integritet. Referentiel integritet Ved referentiel integritet forstås, at sammenhørende data mellem 2 tabeller altid sikres. Danny Stoltenberg Stjerne, Side 4

5 Eksempel: En kundetabel og en ordretabel. Kundetabellen består af alle oprettede definerede kunder. Hver kunde har et unikt kundenummer som primærnøgle. Ordretabellen består bl.a. af et kundenummer og et ordrenummer. Hvis der er mulighed for ændre kundenummeret i kundetabellen, skal man med databasemæssig referentiel integritet sikre sig, at alle rekords i ordretabellen også bliver ændret til det nye ændrede kundenummer for at kunne sige, at der er referencemæssig integritet mellem de 2 tabeller. Sikres dette ikke har vi forældreløse (Engelsk: Orphans) kundenumre i ordretabellen hvor man ikke længere kan finde den korrekte kundebeskrivelse (forælder) i kundetabellen. Det samme problem opstår hvis man sletter en kunde i kundetabellen. På engelsk kalder man også denne sammenhæng mellem de 2 tabeller som et Master/Slave relationship. Kundetabellen er Master (kunde som primærnøgle), og Ordretabellen er Slave (med kundenummer som fremmednøgle). I SQL sproget (ANSI standard) er en mulig sikring af sådan referentiel integritet implementeret med at man kan definere ON DELETE CASCADE og ON UPDATE CASCADE på tabel niveau som kan sikre, at når man enten sletter en rekord eller opdaterer primærnøglen i en hovedtabel så gennemfører databasen en tilsvarende opdatering i underliggende tabeller (der har en fremmednøgle linket op på hovedtabellen). Dermed er der referencemæssig integritet i databasen, men samtidig skal man jo også gøre sig klart, at eksempelvis når man sletter en kunde i kundedatabasen i ovenstående eksempel bliver alle ordrer (og andre transaktioner der tilsvarende ville være hæftet op på kundetabellen) slettet. Man sikrer integriteten, men mister historikken. Hele problemstillingen med historik håndtering og eksempelvis dataware house opbygning vil være for omfattende at komme nærmere ind på i dette skrift. Se nærmere i skrift om Business Intelligence. Semantisk integritet Med semantisk integritet (også af andre kaldet domæne integritet) forstås sikring af at værdier i et givet felt kun indeholder tilladte værdier af det givne domæne. Se definitionen tidligere. Man må ikke forveksle semantisk/domæne integritet med datatypen. Datatypen kan siges at være laveste niveau på attributniveau for semantisk integritet. Datatypen definerer hvilken type af værdier en given attribut kan indeholde, men den definerer ikke domænet (alle valide udfald af værdier). Domænet er som sagt den udfaldsmængde af den givne definerede datatype som attributten/feltet i relationen/tabellen må indeholde. Der er en tydelig problemstilling med hvorledes man sikrer sig semantisk integritet, i at det er endog meget problematisk til alle tider, at have fuld viden om alle mulige udfald af et givent felt. Eksempelvis et felt der må indeholde valide telefonnumre. Hvordan sikrer man sig, at der kun indtastes valide eksisterende telefonnumre i et sådant felt. Danny Stoltenberg Stjerne, Side 5

6 Teoretisk er det enkelt, at forlange semantisk integritet, men i praksis er der for masser af attributters vedkommende store problemer med at sikre dette. I en række tilfælde hvor man på forhånd kun har en vis mængde udfald, som man deslige ønsker bliver registreret ensartet fra transaktion til transaktion, implementerer man ofte dette ved også at benytte referentiel integritet. Udfaldsmængden bliver defineret endeligt i en Master tabel (se ovenfor under referentiel integritet), og der laves så en fremmednøgle fra feltet i den tabel hvor transaktionerne skal lagres til denne mastertabel. Derved sikrer databasen også, at kun værdier der er defineret i mastertabellen (domænet der fuldt defineret) kan indtastes. Dette er god praksis i alle de tilfælde hvor man har muligheden og hvor det er væsentligt at de værdier man registrerer er de samme fra gang til gang (ingen tastefejl, ingen forskel på små og store bogstaver, ingen ugyldige koder etc, men det betyder også samtidigt, at en given virkelighed der skal beskrives hurtigt får rigtig mange hjælpetabeller med definition af domæner. Alle disse domæne definitionstabeller skal jo også vedligeholdes og opdateres. Hvis man gik hele vejen, og havde et domænefelt man havde defineret som alle valide danske telefonnumre, og havde mulighed for at få disse indlæst i en tabel (inklusive hemmelige numre m.m.) ville denne tabel jo nærmest skulle opdateres online real-time for at man kunne være sikker på, at ville være valid. Som det fremgår af ovenstående skal man altså i designet af databasen sikre sig den nødvendige semantiske integritet på de områder hvor det er væsentligt for den model der forsøges at blive implementeret. Rigtig mange applikationer (inklusive danske ERP systemer) er set med store databaser hvor der er væsentlige huller i både den referentielle integritet og i den semantiske integritet. Når man efterfølgende skal lave rapportering på en sådan database og pludselig finder ud af, at der er ting der ikke hænger sammen står man med store problemer. Som minimum skal man sikre sig den nødvendige referentielle integritet, og må sørge for at der er tilstrækkelig semantisk integritet i forhold til både den daglige brug af modellen i forhold til registreringerne og i forhold til en efterfølgende nødvendig rapportering og statistik på de registrerede informationer. Som et underpunkt til den semantiske integritet findes også begrebet overgangs- eller faseskift integritet. Hermed menes, at der kan være en vis udfaldsmængde i domænet (eksempelvis status angivelse / status koder) som skal have en vis rækkefølge. Altså, at man kun kan gå fra en status til en efterfølgende (eller tidligere) alt efter typen. Det kan være en ordre som har forskellige stati i form af: oprettet, under plukning, plukket, pakket, afsendt, leveret, faktureret, betalt e.l.). I disse tilfælde er det ikke nok, at oprette en ekstra tabel med domænets mulige udfald, men man bliver også nødt til at implementere logik (enten direkte i databasen via database programmets muligheder) eller via applikationskode logik der sikrer, at kun valide faseskift sker som defineret. Danny Stoltenberg Stjerne, Side 6

7 Introduktion til normalisering Normalisering som begreb Normalisering som begreb kan have flere betydninger afhængig af hvilken videnskab man arbejder indenfor. Inden for matematikken kan det være en teknik for bevisførelse eller generel transformation fra en tilstand til en anden. Som generelt begreb kan normalisering siges at være, en hvilken som helst proces eller funktion der transformerer noget til en mere normal eller logisk form. Database teoretisk kan man faktisk sige, at der består 3 typer af normalisering, hvoraf de fleste kun er blevet introduceret til den mellemste af nedenstående 3 former:: Felt normalisering (semantisk analyse der fjerner domæne redundans på attribut niveau) Tabel normalisering (fjernelse af redundante data på tabel niveau) Database normalisering (generalisering af tabeller, der fjerner redundante felter ml. tabeller) Felt normalisering Med felt normalisering skal forstås at man semantisk (betydningsmæssigt) forsøger at gennemføre en analyse over en given attributs domæne for at sikre sig, at feltet ikke indeholder flere repeterende informationer der burde splittes op i hver sin attribut i forhold til entitetens definition. Eksempelvis hvis man har et TYPE felt der beskriver eller anfører en eller anden form for kategorisering af den enkelte rekord. Lad os sige, at domænet har følgende udfald: Rød og Lille Rød og Mellem Rød og Stor Gul og Lille Gul og Mellem Gul og Stor Det er klart, at for hver gang man introducerer en ny farve (og dermed udvider domænet) kommer der 3 nye værdier i domænet, og hvis man også introducerer en ny størrelse (f.eks. mellemstor) ja så bliver antallet i domænet ganget op med antallet af definerede farver. I ovenstående situation har vi en multiværdi kombination mellem 2 typer af information på felt niveau. Hver information om farve kan ganges med hver information om størrelse for at give domænets udfald, og dermed har man redundante data i domænet. Dette løses ved at splitte feltet/attributten op i 2 felter. Et felt der indeholder farven, og et felt der indeholder størrelsen. Dette vil de fleste sikkert gøre naturligt allerede ved definitionen af Danny Stoltenberg Stjerne, Side 7

8 klassens/tabellens attributter, men det er ikke et klart defineret krav i normal tabel normalisering at man foretager denne skelnen på feltniveau. Dermed bliver en given farve kun medtaget en gang i farveattributtens domæne, og størrelsen kun en gang i størrelsesfeltets domæne. Har man kun 3 kategorier af størrelse som angivet i ovenstående eksempel vil størrelsesdomænet altså kun bestå af {Lille, Mellem, Stor}. Et felt kan altså siges at være normaliseret når det (efter bedste evne se appendix) ikke indeholder repeterende multiværdi information i domænet. Semantisk feltanalyse skal ikke forveksles med semantisk integritet. Med semantisk feltanalyse undersøges, at domænet ikke har repeterende multiværdi information. Med semantisk integritet forsøger man at sikre sig, at et rekordfelt ikke indeholder en værdi som ikke er defineret i domænet. Tabel normalisering Normalisering af en tabel At normalisere en tabel kan lidt populært siges at sikre at data ikke gentages flere steder når man indtaster flere rækker. Data der står flere steder i samme database kaldes redundante data. Ifølge normaliseringsteori gælder det om at reducere redundante data mest muligt. Første sikring mod redundans er altså på feltniveau at sikre, at der ikke er multi værdi information med repeterende værdier i domænet. Dernæst skal man på tabelniveau sikre, at værdier i det givne felt i mindst muligt omfang repeteres mellem rækkerne. Der findes mange grader af normalisering, hvor man nedbryder en eksisterende tabel til stadig flere tabeller for at sikre ovenstående. Man taler om forskellige normaliseringsformer. Disse går fra tabeller fra 1. normalform til tabeller af 5. normalform (eller 6. normalform). I mange tilfælde vil tabeller der er normaliseret til 3. normalform også være normaliseret 'helt i bund', således at de også er på 4. og 5. normalform. De sidste 2-3 normalformer kan oftest opfattes som specialtilfælde for visse tabeller. Ofte med primærnøgler sammensat af flere felter. Der findes helt formelle definitioner for hvornår en tabel er på en given normalform. I det følgende forsøges disse at blive oversat og forklaret fra den mere formelle definition. Bemærk dog, at tabel normaliseringsteori har en teoretisk tilgangsvinkel med mange teoretikere, og mange forskellige definitioner hvor der er forfattere der faktisk ikke engang er enige om definitionen af 1. normalform. To af de mest kendte forfattere (Edgar F. Codd og Chris Date) har derfor forskellige definitioner af 1. normalform. Der henvises til disse forfattere for nærmere beskrivelser af forskelle eller til søgning på internettet af de 2 definitioner. Se dog også Appendix for en teoretisk diskussion af problemstillingerne ved definitionen af 1. normalform. Danny Stoltenberg Stjerne, Side 8

9 En u-normaliseret tabel. Vi starter med en unormaliseret tabel med 5 oplysninger: Leverandørnummer, Postnummer (på leverandøren), by, produktnr, samt antal. I den unormaliserede tabel er rekord 3 længere (har 2 felter mere hvor produktnr og antal felterne gentages) end de andre rekords. Lev-nr Postnr By Produktnr Antal Produktnr Antal Roskilde 1, 2, 3 100, 150, Viborg 1, 2, 3 100, 100, Roskilde Ålborg 1, 2, 3 100, 125, 175 1NF Tabellen skal have fast rekordlængde og alle rekords skal være ens (en og kun en rekordtype pr. tabel). Hver rekord skal kunne identificeres entydigt (der skal kunne dannes en primærnøgle - dermed er en NULL værdi i nøglen ikke tilladt). Tabellen skal indeholde atomariske værdier. Sammendrag: Hver rekord skal kunne identificeres entydigt, og skal indeholde atomariske værdier. Med angivelsen af, at en rekord skal kunne identificeres entydigt er dette også beskrivelsen af hvad man kalder entitetsintegritet. I ovenstående definition benyttes begrebet atomariske værdier. Dette begreb har været til diskussion, da et tekstfelt jo kan indeholde flere ord, og i teorien vil et sådant felt ikke være atomarisk i sin mest stringente fortolkning. Uden at skulle gå ind i en alt for dyb teoretisk diskussion her, kan man tillægge en praktisk fortolkning af atomarisk således, at et givet felt ikke må indeholde flere værdier af samme type (domæne værdier - eksempelvis et telefonnummerfelt der indeholder flere telefonnumre), eller et felt der indeholder flere værdier af forskellig type (Eksempelvis et felt der både beskriver størrelse og farve: Stor og Rød; Mellem og Grøn; Lille og Rød etc, som beskrevet tidligere under felt normalisering). I disse tilfælde vil tabellen ikke være på 1NF under denne definition. Se nærmere diskussion i Appendix omkring problemerne med definitionen af en normaliseret virkelighed på 1. normal form. Spørgsmål: Er ovenstående tabel på 1NF? - svar: NEJ Første produktnr felt indeholder repeterende værdier (eks: 1, 2 og 3). Det gør første antalfelt også. Ligeledes er der ikke fast rekordlængde, da rekord 3 istedet for at have repeterende værdi i produktnr og antal felterne har gentaget værdierne i 2 ekstra felter, hvorved rekord 3 er længere end de andre. I ovenstående tabel kan man se at en attribut som produktnr indeholder 3 numre (repeterende gruppe), og antal indeholder ligeledes 3 værdier svarende til de 3 produktnumre. En sådan tabel er ikke normaliseret, da hver kolonne skal være atomarisk (der må være en, og kun en værdi i en hver rekords enkelte felter). En anden måde at angive repeterende gruppe på, et at gentage feltet flere gange (i ovenstående tabel er produktnr og antal felterne angivet 2 gange, og dermed udtryk for repeterende værdier i rekord 3). Med atomarisk menes derfor også, at et felt ikke dubleres. Med domæne menes alle de værdier som et givet felt kan/må bestå af. Danny Stoltenberg Stjerne, Side 9

10 Med atomarisk menes altså i praksis: Et felt indeholder en og kun en værdi af det givne domæne, og et givent felt er angivet en og kun en gang i hver rekord/tabel. Et givet felt må kun indeholde en betydning (domæneværdierne har kun et betydningsindhold for brugen af den givne rekord). For at få ovenstående tabel på første normalform, bliver man derfor nødt til at gentage rækkerne, således at kolonnerne kun indeholder 1 værdi, og man fjerner (felt dubletterne) - produktnr og antal kolonnerne. Første normal form. Nu kommer tabellen derfor til at se således ud: L e v - n r P o s tn r By P r o d u k tn r A n ta l R o s k i ld e R o s k i ld e R o s k i ld e V i b o r g V i b o r g V i b o r g R o s k i ld e R o s k i ld e Å lb o r g Å lb o r g Å lb o r g 3 Primærnøgle: Lev-nr+Produktnr 175 2NF Tabellen skal være på 1NF. Alle felter der ikke indgår i primærnøglen skal være fuldt funktionelt afhængige af primærnøglen. Spørgsmål: Er ovenstående tabel på 2NF? - svar: NEJ Med fuldt funktionelt afhængig menes, at et felt der ikke indgår i primærnøglen skal være afhængig af hele nøglen og ikke blot en delmængde af nøglen. I ovenstående tabel består primærnøglen af 2 felter (lev-nr og produktnr), men postnr og by felterne er kun afhængige af lev-nr feltet (de er ikke afhængige af produktnr-feltet), og disse 2 felter indgår ikke i primærnøglen. Disse 2 felter er altså ikke fuldt funktionelt afhængige - de er kun delvist afhængige! Vi bliver derfor nødt til at splitte ovenstående tabel op i 2 tabeller. En tabel der indeholder oplysninger om leverandøren, og de felter der knytter sig til lev-nr (postnr og by), og en anden tabel der indeholder oplysninger om produkterne. Tabellerne skal kunne knyttes sammen (i en 1-tilmange relation), så vi må også angive lev-nr feltet i produkttabellen. Bem: En tabel der er på første normalform, og hvor primærnøglen kun består af et felt, vil derfor også altid være på anden normalform! Danny Stoltenberg Stjerne, Side 10

11 Anden normalform. Leverandørtabel Lev-nr Postnr By Roskilde Viborg Roskilde Ålborg Produkttabel Lev-nr Produktnr Antal Primærnøgle Leverandørtabel: Lev-nr Primærnøgle Produkttabel: Lev-nr+Produktnr Leverandør Lev-nr Postnr by Produkter Lev-nr Produktnr Antal For at knytte ovenstående tabeller sammen skal der laves en fremmednøgle på produkttabellens levnr, der knytter sig til leverandørtabellen (pilen anigvet mellem tabellerne). I ovenstående tabeller er felter der ikke indgår i primærnøglerne fuldt funktionelt afhængige af primærnøglerne. Bemærk, at tabellen på første normalform godt kunne opfattes som en klasse, men at vi via normaliseringsteorien får fundet frem til at det faktisk er 2 logiske klasser. 3NF Tabellen skal være på 2NF. Alle felter der ikke indgår i primærnøglen må ikke være transitivt afhængige af primærnøglen. Spørgsmål: Er ovenstående tabel på 3NF? - svar: NEJ Med ikke være transitivt afhængige menes, at felter der ikke indgår i primærnøglen ikke må have nogen form for indbyrdes afhængighed eller relationer. Eksempelvis indeholder leverandørtabellen 2 felter der ikke indgår i primærnøglen (postnr og by). Både By og postnrfelterne er fuldt afhængige/tilknyttede til lev-nr feltet, men der er samtidig en sammenhæng mellem bynavn og postnr. Der er altså en form for tilknytning mellem 2 felter der ikke indgår i primærnøglen! Vi kan altså gå fra leverandørfeltet til by og derudfra udlede postnr. Vi bliver derfor nødt til at splitte leverandør tabellen op i 2 tabeller, således at postnr og by felterne ikke begge knytter sig til lev-nr feltet. Danny Stoltenberg Stjerne, Side 11

12 Tredje normalform / Boyce-Codd Normalform 3. Normalform Leverandørtabel Postnrtabel Lev-nr Postnr Postnr By Roskilde Viborg Ålborg Produkttabel Lev-nr Produktnr Antal Primærnøgle Leverandørtabel: Lev-nr. Primærnøgle Postnrtabel: Postnr Primærnøgle Produkttabel: Lev-nr+Produktnr For at knytte de 3 tabeller sammen skal man som på 2NF have en fremmednøgle i produkttabellens lev-nr der refererer til leverandørtabellen. Ligeledes skal man have en fremmednøgle på leverandørtabellens postnr felt der refererer til postnrtabellen (pile med tabeller). Som man kan se af ovenstående tabeller er der nu ikke længere felter der ikke indgår i primærnøglerne som er indbyrdes afhængige. I ovenstående tabeller er der nu kun et felt i hver tabel der ikke indgår i primærnøglen, og derfor kan der heller ikke være et afhængighedsforhold mellem felter der ikke indgår i primærnøglen: Tabel Primærnøgle Felter ikke i primærnøgle Leverandørtabel Lev-nr Postnr Postnrtabel Postnr By Produkttabel Levnr+Produktnr Antal Bemærk at tabellerne på 2. normalform kunne opfattes som 2 klasser, men at vi via normaliseringsteorien får analyseret os frem til at der faktisk er 3 logiske klasser! Danny Stoltenberg Stjerne, Side 12

13 Boyce-Codd Normalform (BCNF) BCNF omhandler tabeller, hvor man kan forestille sig attributter en eller flere andre attributter er fuldt afhængige af (determinant), hvor denne attribut (eller sammensatte attribut) samtidig skal kunne være primærnøgle (alle determinanter skal være kandidatnøgler). En sådan tabel er på 3 normal form og også på BCNF. Er tabellen på 3. normal form, men der kan findes en eller flere af ovenstående attributter (også kaldet determinanter) som ikke samtidig kan være primærnøgle for hele tabellen er tabellen ikke på Boyce/Codd normal form, men kan opdeles i 2 tabeller. Hvis en determinant er en del af en primærnøgle, og denne determinant ikke kan være en primægnøgle i sig selv, er tabellen ikke på BCNF. Man skal altså teste alle felter i tabellen for om de er determinanter, og om alle determinanter kan være primærnøgler. BCNF er en skærpelse af 3. normalform. BCNF En derterminant er et felt (eller et sammensat felt af flere felter) som en eller flere andre felter er fuldt afhængige af. En tabel er på BCNF hvis alle determinanter er kandidatnøgler (kan være primærnøgle) for tabellen. Hvis vi ser på produkttabellens felter for at lede efter determinanter kan det ses at på enkeltfelt niveau er der ingen determinanter. Der er ingen afhængighed mellem produktnummer og leverandørnummer, og der er ingen afhængighed mellem disse felter individuelt og antal. Til gengæld er der en afhængighed mellem antal og den sammensatte determinant bestående af leverandørnummer og produktnummer, men der er ikke andre determinanter. Da dette er tilfældet, er tabellen også på Boyce-Codd s normalform. Generelt om Fjerde og Femte og øvrige normalformer Dette er ofte spekulative og mere teoretiske normaliseringsformer som tit er teoretisk konstruerede end egentlige tabeller man ofte støder på i virkeligheden. Ofte er dette tabeller hvor eksemplet angives til at have sammensatte primærnøgler bestående af 2-3 felter med repeterende værdier inde i nøglen hvorfor disse til tider kan normaliseres yderligere for at fjerne redundansen. Hvis en tabel derfor er normaliseret til et niveau hvor nøglen kun består af 1 (et) felt, og der ikke er andre kandidatnøgler (andre mulige nøglefelter) vil tabellen ikke kunne normaliseres yderligere. Er en tabel bestående af en sammensat primærnøgle skal man altså undersøge om der er repeterende værdier i primærnøglen hvilket ofte er tilfældet da man netop er nødt til at sammensætte 2 (eller flere) felter for unikt at kunne identificere en given rekord, og derved er minimum 1 af felterne i primærnøglen ikke unik men har flere værdier der går igen. Hvis det er tilfældet kan tabellen til tider splittes op i 2 eller flere nye tabeller indtil man har normaliseret ned til et niveau hvor tabellen kun har et felt der udgør primærnøglen, og hvor der ikke er andre kandidatnøgler som primærnøgle. Alternativt ned til et niveau hvor tabellens felter tilsammen udgør primærnøglen og hvor disse felter ikke kan opdeles i flere tabeller der tilsammen kan skabe informationen fra denne tabel. Danny Stoltenberg Stjerne, Side 13

14 Fjerde normalform (4NF) 4NF er en nedbrydning af en tabel, når der eksisterer 2 felter som er uafhængige af hinanden, men begge er afhængige af et andet felt og kan kombineres (multipliceres af deres respektive værdier). Dette kaldes også på dansk for multiværdi afhængighed. Kravet er altså, at der ikke må eksistere felter hvor værdierne i disse domæneer/felter skal multipliceres for at give alle udfald: eksempelvis en tabel med 3 felter: Bilmodel, Motortype (benzin, diesel), farve. Hvis der er 2 bilmodeller (sedan og Stationcar) 2 motortyper (Benzin og Diesel) og 3 farver og alle modeller kan leveres i alle farver er der altså 12 kombinationer og dermed 12 rekords under de givne domæne definitioner.vi har derved en multiværdi afhængighed hvor en given kombination af motortype og farve vil kunne byttes om mellem rekords og give samme udfald for alle kombinationer. Det er også klart, at denne tabel indeholder redundant information. Det er også klart, at der ikke eksisterer fuld afhængighed mellem nogle af disse felter. Farven er ikke bestemt af hverken bilmodel eller motortype, motortype er ikke bestemt af hverken bilmodel eller farve, og bilmodellen er ikke bestemt af hverken motortype eller farve. Altså er der ingen kombination af 2 felter der er determinanter under BCNF. Omvendt er der et klart defineret værdisæt af motortyper og farver der kan vælges imellem til hver bilmodel. Bilmodel Motortype Farve Sedan Benzin Rød Sedan Benzin Gul Sedan Benzin Grøn Sedan Diesel Rød Sedan Diesel Gul Sedan Diesel Grøn Stationcar Benzin Rød Stationcar Benzin Gul Stationcar Benzin Grøn Stationcar Diesel Rød Stationcar Diesel Gul Stationcar Diesel Grøn I en sådan tabel ville alle 3 felter skulle sammensættes for at udgøre primærnøglen. Da der ikke eksistererer andre determinanter end primærnøglen vil tabellen derfor være på BCNF form. Ligeledes vil den kunne splittes op i 2 tabeller (Bilmodel, Farve og Bilmodel, Motortype), hvor vi har fjernet redundant information, således at i tabellen bil/motortype er der 4 rekords, og i tabellen bil/farve er der 6 rekords. I hver tabel er begge felter stadig en del af primærnøglen, og der er stadig repeterende værdier i primærnøglen, men tabellerne kan ikke nedbrydes yderligere uden tab af information. Danny Stoltenberg Stjerne, Side 14

15 Bilmodel Farve Bilmodel Motortype Sedan Rød Sedan Benzin Sedan Gul Sedan Diesel Sedan Grøn Stationcar Benzin Stationcar Rød Stationcar Diesel Stationcar Gul Stationcar Grøn 4NF En tabel er på 4NF hvis - når der eksisterer en flerværdi afhængighed fra eksempelvis felt A - alle felter i en given rekord være funktionelt afhængige af A. Hermed menes, at består en tabel eksempelvis som benævnt ovenfor af 3 felter a,b, og c, hvor b og c hver har en givet sæt af kombinærbare værdier i forhold til a, skal enhver kobination af b,c unikt kunne identificeres af a. Dette er ikke tilfældet i det nævnte eksempel da b og c kan kombineres på forskellig vis til samme a værdi. Splitter man derimod tabllen op i 2 tabller a,b og a,c som vist ovenfor af mulige kombinationer, vil der kun være en farve til hver biltype, og en motortype til hver biltype. Der vil da ikke eksistere en multiværdi afhængighed, og da der ikke er nogle funktionelle determinanter, er disse 2 tabller altså både på BCNF og 4NF. Femte normalform (5NF) Hvis vi tager foregående eksempel under 4. normal formog udskifter farve med sælger, kan man forestille sig følgende tabel: Bilmodel Motortype Sælger Sedan Benzin Hansen Sedan Diesel Hansen Sedan Diesel Jensen Sedan Diesel Olsen Stationcar Benzin Hansen Stationcar Diesel Hansen Stationcar Diesel Jensen En given sælger kan sælge en given bilmodel med en given motortype under nogle givne forudsætninger. I ovenstående er der den forudsætning, at hvis en given sælger kan sælge en motortype gælder det for alle bilmodeller. Det er ikke sikkert, at en sælger er tilladt at sælge alle kombinationer, men omvendt kan en sælger måske godt have tilladelse til at sælge alt. Herved er der ikke en afledt afhængighed mellem motortype og bilmodel. Ej heller afhængighed mellem hverken sælger og motortype eller sælger og bilmodel. Alene alle 3 felter udgør primærnøglen for tabellen, og der er ikke andre determinanter, så tabellen er på BCNF. Ligeledes kan motortype og sælger ikke per automatik kombineres, så der eksisterer ikke en flerværdi afhængighed, så tabellen kan også siges at være på 4. normal form. 5NF En tabel er på 5. normalform hvis alle join-afhængigheder i tabellen er en konsekvens af tabellens kandidatnøgler. Danny Stoltenberg Stjerne, Side 15

16 I en tabel hvor felterne x1,x2,x3,...,xn er en delmængde af tabellens felter siges join-afhængigheden at eksistere for denne delmængde af felter såfremt enhver forekomst af rækker i tabellen kan dannes ud fra projektionerne af tabellen på delmængderne af x1,x2,x3,...,xn. Ovenstående tabel er derfor ikke på 5. normalform. Tabellen kan opsplittes i 3 tabeller således at en projektion af disse 3 tabeller kan skabe ovenstående informationer. Se tabellerne nedenfor. Bilmodel Sælger Motortype Sælger Bilmodel Motortype Sedan Hansen Benzin Hansen Sedan Benzin Sedan Jensen Diesel Hansen Sedan Diesel Sedan Olsen Diesel Jensen Stationcar Benzin Stationcar Hansen Diesel Olsen Stationcar Diesel Stationcar Jensen I ovenstående tabeller har man angivet hvilken sælger der kan sælge hvilke bilmodeller. Ligeledes hvilken sælger der kan sælge hvilke motortyper, og sidst hvilke bilmodeller der har hvilke motortyper i udgangstabellen. Eksempelvis kan man ved at sammenkøre (joine) informationeerne fra disse 3 tabeller kunne komme tilbage til udgangspunktet i den første tabel. Det fremgår eksempelvis af ovenstående, at Sælger Olsen alene kan sælge bilmodellen Sedan med en Dieselmotor. Ligeledes fremgår det, at Sælger Hansen kan sælge både Sedan og Stationcar og begge både med Benzin og Dieselmotor (da det fremgår af sidste tabel at begge bilmodeller sælges med begge motortyper. Ligeledes kan det ses af ovenstående, at kun sælger Hansen kan sælge bilmodeller med benzin motorer. Informationerne i ovenstående tabeller kan ikke opsplittes i yderligere tabeller uden tab af information. Hver af ovenstående 3 tabeller har begge felter som primærnøgle, og i disse er der repeterende værdier, men i dette tilfælde vil man ikke kunne opsplitte informationen yderligere. Bemærk ligeledes, at hvis man ændrer præmisserne for den virkelighed der skal beskrives således at man kunne forestille sig, at en sælger eksempelvis godt kunne sælge en given bilmodel med en given motortype, men ikke en anden bilmodel med samme motortype ville man ikke kunne foretage denne projektion uden tab af information. Lad os antage, at sælger Jensen i den oprindelige tabel dermed stod til også at kunne sælge bilmodel Sedan med Benzin motor, men ikke var tilladt at kunne sælge Stationcar med benzin motor ville projektionerne i de 3 tabeller ikke længere være gældende. Vi ville ikke kunnne repræsentere den givne viden i de 3 underliggende tabeller. Sælger Jensen ville stå til at kunne sælge både Benzin og Diesel i tabellen (motortype, sælger), og ligeledes vil han stå til at kunne sælge både Sedan og Stationcar i tabellen (bilmodel, sælger), men informationen om at han kun må sælge benzin motor udgaven af Sedan modellen og ikke i stationcar udgaven vil dermed være tabt. Dermed vil man ikke kunne gendanne den nødvendige information via projektionerne fra de underliggende tabeller. Under 4. normal forms eksempel opsplittede man en tabel med 3 felter (a,b,c) i 2 tabeller med to felter på formen a,b og a,c der tilsammen indeholdt samme information som den tabel hvorfra disse blev udledt. Dette skyldes multiværdi afhængighed. Under 5. normal forms eksempel opsplittede man en tabel med 3 felter (a,b,c) i 3 tabeller med to felter på formen a,b og a,c og b,c (alle kombinationer af attributter nødvendige) for at kunne genskabe informationen fra den tabel hvor informationen kom fra. Danny Stoltenberg Stjerne, Side 16

17 Andre normalformer I litteraturen (Se bl.a. på engelsk beskrivelse om Database Normalization på kan der bl.a. læses om Domain/Key normal form og Sjette normalform. Her kan man bl.a. også læse om 6. normal form. Domain/Key er ikke at betragte som en 6. normal form i sin puristiske definition, men er mere en teoretisk anderledes begrebsanalyse til at betragte tabeller på ud fra en normaliserings synspunkt. Der er dog ikke angivet en klar og entydig metodik til at benytte DK/NF til at få alle tabeller normaliseret i bund. Domain/Key eksemplet på ovenstående link kan dog diskuteres om overhovedet er på første normalform, da eksemplet indeholder fler-betydnings information i samme attribut med repeterende værdier i domænet, og dermed ikke er blevet normaliseret på felt niveau, men der henvises herved til appendix for en nærmere diskussion af definitions problematikken med 1. normalform. Fordele og ulemper ved tabel normalisering. Fordelen ved tabel normalisering ligger på flere områder: - Vedligeholdelse lettes (i form af indsættelse af nye data, opdatering og sletning) (i de fleste tilfælde) - Fleksibilitet og overblik (kan også give mindre overblik) - Pladsbesparelse (fjernelse af redundante data). Vedligeholdelse, fleksibilitet og overblik. Har man kun data liggende et sted, er det betydeligt lettere at vedligeholde (og det sparer oftest plads). Eksempelvis hvis vi ved at ovenstående 3 tabeller i beskrivelsen af 3. normalform der er på 3. normalform er forbundet med fremmednøgler ville man blot kunne ændre eksempelvis leverandørnummer 1 til nummer 10, og være sikre (under forudsætning af at man arbejder med fuld integritet - altså med CASCADE UPDATES og CASCADE DELETES) på at alle data er opdaterede i alle tabeller. Da data ligeledes er placeret i logisk sammenhængende tabeller (logiske klasser), har man også større overblik over hvor de enkelte oplysninger findes, og evt. ny funktionalitetsbehov for programmet er ikke så afhængig af den fysiske lagringsstruktur. Pladsbesparelse. Den anden fordel ved normalisering er pladsbesparelse. Når man undgår repeterende værdier fylder data ikke så meget, og derved vil man spare plads i databasen og harddisken (som udgangspunkt). Danny Stoltenberg Stjerne, Side 17

18 Umiddelbart kan man ikke se dette ud fra ovenstående eksempler, når tabellen indeholder så få rekords, men i visse transaktionssystemer tales der sommetider om millioner af transaktioner per dag eller per time, og da er en enkelt byte af betydning for databasens størrelse. Ulemper ved normalisering. Der er også ulemper ved normalisering. Hvor godt det end lyder med lettere vedligeholdelse større fleksibilitet, større overblik og pladsbesparelse, kan uigennemtænkt normalisering faktisk risikere at være det modsatte! Dette skyldes, at hvis man blot normaliserer uden at gennemtænke hvorfor man normaliserer, kan man komme til at få flere ulemper end fordele. Mulige ulemper kan eksempelvis være: - Mange tabeller betyder lavere performance (access af flere tabeller). - Den faktiske brug af systemet kan altså være af betydning for normaliseringsgraden - Mange relationer med fremmednøgler, betyder mange indeks, hvilket igen betyder (se afsnit 2.3): - Forøget plads til indeks - Forøget procestid til opdatering af indeks - Mange tabeller kan betyde mindre overblik: - Hvor er et givet felt placeret? - Hvorledes hænger data egentlig logisk sammen? Man skal derfor ikke ukritisk normalisere. Afvejede behov. Desværre kan man ofte læse diverse kommentarer, at ikke fuldt tabel normaliserede databaser er udtryk for dårligt database design. Dette er ikke nødvendigvis altid tilfældet. Afgørende er hvad databasen skal bruges til, og hvilke slutbrugerbehov der skal løses. Man må altså afveje en lang række krav og behov til det edb-system man vil udvikle og hvor databasen skal benyttes og afveje fordelene ved tabel normalisering op mod ulemperne. Danny Stoltenberg Stjerne, Side 18

19 Database normalisering Generalisering af tabeller Et punkt som ikke får mange bemærkninger eller fokus i undervisning omkring database modellering i forhold til eksempelvis tabel normalisering er begrebet generalisering (og specialisering). Disse begreber kendes primært fra den objekt-orienterede teori, men gælder i høj grad også for databaser. Emnet har været beskrevet siden 1970 erne, men som sagt fylder dette emne langt mindre i database teori bøger end tabel normaliserings teorien gør. Mange databaser består af ikke-generaliserede tabeller. Tabel normalisering foregår altid på enkelt tabel niveau. En tabel kan blive til flere tabeller ved at redundante data i rekords bliver fjernet ved at tabellen bliver splittet op således at data kun indgår en gang. Ved generalisering ser man ikke på den enkelte tabel, men ser på om felter (domæne data) er redundante på tværs af tabeller. Altså om de samme felter (samme logiske indhold) indgår i flere tabeller. Hvis dette er tilfældet er det muligt at overveje en generalisering. Her kommer et eksempel med en kunde og en leverandør tabel: KUNDE TABEL Kundenr Kundenavn Adresse1 Adresse2 Postnr Land Tlf.nr kreditmax ABC-kode Rabat% 1 Eriksen A/S Husvej 2 Lyssinge 4123 Danmark ,00 B 10 2 Hansen Imp. Bådvej Danmark ,00 C 3 3 Trafico Pigvej Danmark ,00 A 15 LEVERANDØR TABEL Lev.nr Lev.navn Adresse1 Adresse2 Postnr Land Tlf.nr Kretitmax Min.køb Lev.Tid 1 Larsen vin Rossevej Danmark ,00 300,00 5 Ser man på de 2 tabeller indeholder disse en række felter som er helt identiske. Disse 2 tabeller kan faktisk generaliseres således at de felter som er ens fjernes fra de 2 tabeller og lægges over i en ny tabel. Der skal dog så samtidig oprettes en hjælpetabel som beskriver om det er en kunde eller en leverandør der er i den generaliserede tabel: Danny Stoltenberg Stjerne, Side 19

20 TYPE TABEL Type Typetekst K Kunde L Leverandør ADRESSE TABEL Type Nummer Navn Adresse1 Adresse2 Postnr Land Tlf.nr Kretitmax K 1 Eriksen A/S Husvej 2 Lyssinge 4123 Danmark ,00 K 2 Hansen Imp. Bådvej Danmark ,00 K 3 Trafico Pigvej Danmark ,00 L 4 Larsen vin Rossevej Danmark ,00 LEVERANDØR TABEL Nummer Min.køb Lev.Tid 4 300,00 5 KUNDE TABEL Nummer ABC-kode Rabat% 1 B 10 2 C 3 3 A 15 I objekt-orienteret tankegang er det udtryk for at adresse tabellen er en generaliseret klasse som leverandør- og kundetabellerne arver fra, og disse indeholder så kun de specialiserede felter som er unikke for deres klasse. Ovenstående eksempel er faktisk en ret simplificeret generalisering, da der kan generaliseres så klart, at navn og type IKKE indgår i adresse tabellen, men alene et adresse nummer, og så selve adresse informationerne. Derved vil kan kunne benytte tabellen således at hvis en kunde samtidig er leverandør og eksisterer både i kunde tabellen og leverandør tabellen henvises alene til et adresse nummer, som i dette tilfælde er det samme. Dette kan ses i nedenstående eksempel: Kunder Kundenr Kundenavn AdresseNr Kreditkode ABC kode Rabat% 1 Eriksen A/S B 10 2 Hanen Imp C 3 3 Trafico A 15 Leverandør Lev. Nr Lev Navn AdresseNr Kreditkode Tlf nr Min køb Lev tid 1 Larsen vin Adresser Postnr Kredit info Adressenr Vej Nr Adresse2 Postnr Postnr By Land Kreditkode Beløb 100 Husvej 2 Lyssinge Rosenby Danmark Bådvej RosOverby Danmark Pigvej NedreUnder Danmark Rossevej Aarhus Danmark I dette nye eksempel er Adresser og Kredit information generaliseret således at data i de to tabeller for kunder og leverandører alene refererer til en adresse kode og det same gælder for kredit information. I dette tilfælde vil en kunde der også er leverandør blot kunne have den samme Danny Stoltenberg Stjerne, Side 20

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

Side 1. Databaser og SQL. Dagens gang. Databasebegreber. Introduktion til SQL Kap 1-5 Databaser og SQL Introduktion til SQL Kap 1-5 1 Dagens gang Databaser Database begreber Mapning af klasser til relationel model Normalisering Opgaver til næste gang 2 Databasebegreber A database is a:

Læs mere

Begrænsninger i SQL. Databaser, efterår 2002. Troels Andreasen

Begrænsninger i SQL. Databaser, efterår 2002. Troels Andreasen Databaser, efterår 2002 Begrænsninger i SQL Troels Andreasen Datalogiafdelingen, hus 42.1 Roskilde Universitetscenter Universitetsvej 1 Postboks 260 4000 Roskilde Telefon: 4674 2000 Fax: 4674 3072 www.dat.ruc.dk

Læs mere

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

Databaser. Område / Specialefag nr. 6238 Database, design og programmering 44954. Datatekniker Infra & Prog IT-Supporter AMU Kursister Databaser Område / Specialefag nr. 6238 Database, design og programmering 44954 Datatekniker Infra & Prog IT-Supporter AMU Kursister Fagligt indhold Link til faget på mars.tekkom.dk Link til faget på iu.amukurs.dk

Læs mere

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

Datamodeller. 1. Elementerne. Vi betragter E/R-diagrammet, som et diagram over entiteter og relationer Tegneregler: Entitet 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

Læs mere

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

Databaseteori. 19. Databaser. 20. Kartotek eller database. 21. Database Databaseteori 19. Databaser Fra længe før EDB alderen har man haft arkiver med viden: lande har haft folkeregistre med oplysninger om landet borgere, firmaer har haft oplysninger om kunder og salg, man

Læs mere

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database

Kursusbeskrivelse. Forarbejde. Oprettelse af en Access-database Kursusbeskrivelse Oprettelse af en Access-database Som eksempel på en Access-database oprettes en simpelt system til administration af kurser. Access-databasen skal indeholde: et instruktørkartotek et

Læs mere

Introduktion til SQL

Introduktion til SQL Introduktion til SQL Introduktion til SQL 1. udgave, 1. oplag 2013 Copyright 2013 Libris Media A/S Forfatter: Bobby Henningsen Forlagsredaktion: Peter Wiwe og Louise Peulicke Larsen Omslag: Louise Peulicke

Læs mere

Data lagring. 2. iteration (implement backend)

Data lagring. 2. iteration (implement backend) Data lagring 2. iteration (implement backend) Emner Grundlæggende database begreber. Data definitionskommandoer ER-diagrammer og cardinalitet/relationer mellem tabeller Redundant data og Normalisering

Læs mere

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

ER-modellen. Databaser, efterår 2002. Troels Andreasen. Efterår 2002 Databaser, efterår 2002 ER-modellen Troels Andreasen Datalogiafdelingen, hus 42.1 Roskilde Universitetscenter Universitetsvej 1 Postboks 260 4000 Roskilde Telefon: 4674 2000 Fax: 4674 3072 www.dat.ruc.dk

Læs mere

Virksomhedens informationssystem. Det elektroniske kontor. Elektronisk dokumenthåndtering Samfundet. Systembeskrivelse II IT og økonomi

Virksomhedens informationssystem. Det elektroniske kontor. Elektronisk dokumenthåndtering Samfundet. Systembeskrivelse II IT og økonomi Virksomhedens informationssystem Systembeskrivelse II IT og økonomi Det elektroniske kontor Elektronisk dokumenthåndtering Hvordan omlægger vi arbejdsgange, så elektronikken styrker vores arbejde? Data

Læs mere

Skriftlig opgave. Designtanker i database-nære systemer

Skriftlig opgave. Designtanker i database-nære systemer Skriftlig opgave til eksamen for faget»databaser«designtanker i database-nære systemer Martin Ancher Holm Juni 2010 1 Intro Denne skriftlige opgave indeholder kort de daglige tanker jeg har omkring design

Læs mere

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4

15. oktober. Maskine Udlejning. Jacob Weng, Jeppe Boese og Mads Anthony. Udlejningsvirksomhed. Roskilde Tekniske Gymnasium 3.4 Maskine Udlejning 15. oktober 2010 Jacob Weng, Jeppe Boese og Mads Anthony Roskilde Tekniske Gymnasium Udlejningsvirksomhed 3.4 Indholdsfortegnelse Problemformulering:... 2 Planlægning:... 2 Analyse af

Læs mere

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014 2014 Tidsregistrering Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4 Informationsteknologi B Roskilde Tekniske Gymnasium 25-11-2014 Indholdsfortegnelse 1 Indledning... 3 2 User stories... 3 3

Læs mere

DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API

DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API DaTelTek ApS ich 4 SpAPI Telenor Serviceprovider API Release 4.0.0 DaTelTek ApS Birkevej 4 DK-4640 Faxe Denmark CVR: 31 06 05 59 +45 32 22 22 22 www.dateltek.dk info@dateltek.dk Indholdsfortegnelse Ændring

Læs mere

Smagsprøve. Databasedesign med Access 2000

Smagsprøve. Databasedesign med Access 2000 Smagsprøve Databasedesign med Access 2000 Helle Frederiksen ISBN: 87-7843-409-2 Link: Http://idgforlag.dk/vp.asp?i=87-7843-409-2 Indholdsfortegnelse, forord og første kapitel Copyright IDG Forlag IDG Forlag

Læs mere

Anvendelse af dobbelthistorik i GD2

Anvendelse af dobbelthistorik i GD2 Grunddataprogrammet under den Fællesoffentlige Digitaliseringsstrategi GD2 - Adresseprogrammet Anvendelse af dobbelthistorik i GD2 Implementerings regler og eksempler på dobbelthistorik MBBL- REF: Version:

Læs mere

Skriftlig eksamen i Databaser, Vinter 2001/2002. Pa opfordring har jeg udarbejdet mulige lsninger pa eksamensopgaverne, men

Skriftlig eksamen i Databaser, Vinter 2001/2002. Pa opfordring har jeg udarbejdet mulige lsninger pa eksamensopgaverne, men Roskilde Universitetscenter Skriftlig eksamen i Databaser, Vinter 2001/2002 Opgaver med lsninger Pa opfordring har jeg udarbejdet mulige lsninger pa eksamensopgaverne, men har ikke haft tid til at polere

Læs mere

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret Håndbog Til CPR services Bilag 8 GCTP-standard m.m. CPR-kontoret Datavej 20, Postboks 269, 3460 Birkerød E-post: cpr@cpr.dk. Telefax 45 82 51 10. Hjemmeside: www.cpr.dk Side 2 af 14 Indholdsfortegnelse

Læs mere

Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen

Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen Karakterer og fritagelse 02-04-2008/version 1.0/Steen Eske Christensen Indhold Ændringer Centrale begreber Generelt Arbejdsgange Vejledningen består af 3 dele, som kan læses hver for sig. Du kan derfor

Læs mere

Software Projekt NoSQL vs RMDB

Software Projekt NoSQL vs RMDB Software Projekt NoSQL vs RMDB Skrevet af Carsten Sørensen, Hans Jørgen Frandsen, Peter Haislund Department of Computer Science, University of Aarhus Aabogade 34, 8200 Arhus N, Denmark 201200089, 19960442,

Læs mere

Øvelse 9. Klasser, objekter og sql-tabeller insert code here

Øvelse 9. Klasser, objekter og sql-tabeller insert code here Øvelse 9. Klasser, objekter og sql-tabeller Denne opgave handler om hvordan man opbevarer data fra databasekald på en struktureret måde. Den skal samtidig give jer erfaringer med objekter, der kommer til

Læs mere

Indholdsfortegnelse Databaser og PHP... 3 Opgave... 4 Opgave... 5 Opgave... 6 Sidste opgave er en lille gæstebog... 7 Kilder og nyttige links:...

Indholdsfortegnelse Databaser og PHP... 3 Opgave... 4 Opgave... 5 Opgave... 6 Sidste opgave er en lille gæstebog... 7 Kilder og nyttige links:... Indholdsfortegnelse Databaser og PHP... 3 Opgave... 4 Opgave... 5 Opgave... 6 Sidste opgave er en lille gæstebog... 7 Kilder og nyttige links:... 9 Nogle HTML tags... 9 Databaser og PHP Når vi snakker

Læs mere

Opgave 1. Opret de 4 tabeller i FTSFrontend programmet. Indsæt mindst 3 forskellige tabelværdier i kunder, målerstatus, byer og regning..

Opgave 1. Opret de 4 tabeller i FTSFrontend programmet. Indsæt mindst 3 forskellige tabelværdier i kunder, målerstatus, byer og regning.. Side 1 af 11 Dato: 07-09-2003 Opgaver i oprettelse af kunder og info i database med java. Opgave 1. Opret de 4 tabeller i FTSFrontend programmet. Indsæt mindst 3 forskellige tabelværdier i kunder, målerstatus,

Læs mere

Axapta 3.0 Konverteringsvejledning

Axapta 3.0 Konverteringsvejledning Axapta 3.0 Konverteringsvejledning ectrl Dokumentversion 3.0 Juli 2008 - Datakonvertering 2008 Side 1 af 14 Indholdsfortegnelse DATAKONVERTERINGSVÆRKTØJET:...3 KARTOTEK INFORMATIONSOVERSIGT - FANEBLAD...5

Læs mere

Data Warehouse Knowledge is Power - Sir Francis Bacon -

Data Warehouse Knowledge is Power - Sir Francis Bacon - Data Warehouse 4. sem. datamatiker uddannelse Tietgen Skolen Odense Skrevet af Troels Markvard Andersen (DM08228) Knowledge is Power - Sir Francis Bacon - Troels Markvard Andersen Side 1 af 8 Forord /

Læs mere

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

Databasesystemer, forår 2005 IT Universitetet i København. Forelæsning 3: E-R modellering. 17. februar 2005. Forelæser: Rasmus Pagh Databasesystemer, forår 2005 IT Universitetet i København Forelæsning 3: E-R modellering 17. februar 2005 Forelæser: Rasmus Pagh Forelæsningen i dag Datamodellering hvad, hvornår, hvorfor og hvordan? Business

Læs mere

Integration af DocuBizz og Helios

Integration af DocuBizz og Helios Integration af DocuBizz og Helios v. 0.2 Side 1 af 7 Integration af DocuBizz og Helios 1 Overordnet beskrivelse... 1 2 Format for de overførte data... 1 3 Overførsel af stamdata fra Helios til DocuBizz...

Læs mere

Produktdokumentation

Produktdokumentation DATABASETIL WEBSITET WWW.SKOERT.DK... 2 BESKRIVELSE OG KATEGORISERIG:...2 ER DIAGRA SKITSER...4 ER diagram nr 1 for hele databasen... 4 Erdiagramskite 2 alternativ løsning til børn... 4 Erdiagramskite

Læs mere

Object-Relational Mapping

Object-Relational Mapping Object-Relational Mapping Skriftligt arbejde i forbindelse med eksamen i Databaser for udviklere Studerende: Henrik Rossen Jakobsen Vejleder: Allan Helboe 07-06-2010 Indhold Indledning... 2 Problemformulering...

Læs mere

DATABASE Projekt 1-3. semester

DATABASE Projekt 1-3. semester DATABASE Projekt 1-3. semester Gruppe 2- CLmul-a12e Projekt URL http://www.lucasperch.dk/projekter/database.pdf Gruppe 2 Lucas Perch-Nielsen cph-lp14@cphbusiness.dk http://lucasperch.dk/skole.php Niclas

Læs mere

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails

Casper Fabricius http://casperfabricius.com. ActiveRecord. O/RM i Ruby on Rails Casper Fabricius http://casperfabricius.com ActiveRecord O/RM i Ruby on Rails Casper Fabricius Freelance webudvikler - casperfabricius.com 9 års erfaring med webudvikling 6 år med ASP/ASP.NET/C# 3 år med

Læs mere

Kommentar fra KMS til Specifikation af Serviceinterface for Person

Kommentar fra KMS til Specifikation af Serviceinterface for Person Kommentar fra KMS til Specifikation af Serviceinterface for Person Organisation Side Kapitel Afsnit/figur/tabel /note Type af kommentar (generel (G), redaktionel (R), teknisk (T)) Kommentar KMS-1 G Godt

Læs mere

Bruger v1.5 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk

Bruger v1.5 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk Bruger v1.5 QUICK GUIDE Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk INTRODUKTION TIL REKVI-SKOLE Ideen med Rekvi-skole systemet udsprang fra et behov

Læs mere

SelskabMasterKom. Per Kjærulf-Møller ApS 13. november 2008. KomTabel-layout. Art: 41 Sendes: Begge veje

SelskabMasterKom. Per Kjærulf-Møller ApS 13. november 2008. KomTabel-layout. Art: 41 Sendes: Begge veje SelskabMasterKom Bemærkninger: Ny protokol (opr. Art 11) Generelt : 1. + 2. byte = RecordArt 3. byte = Transaktionskode 1 = Opret 2 = Ændring 3 = Slet Email og Hjemmeside reduceret til 30 kar. Samlet længde

Læs mere

Rette bunkefejl i Legacy

Rette bunkefejl i Legacy Rette bunkefejl i Legacy - med programmet Microsoft Access Indhold Programmet Microsoft Access... 1 Oprette korte stednavne... 3 Den tunge måde at rette på... 3 Den lettere måde... 4 Slette stednavne...

Læs mere

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S

24-03-2009. Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S 24-03-2009 Problemstilling ved DBK integration i BIM Software Hvad skal der til. Nicolai Karved, Betech Data A/S Problemstilling ved DBK integration i BIM Software Domæner og aspekter Det domæne, der primært

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

Tlf. +45 7027 1699 Fax + 45 7027 1899

Tlf. +45 7027 1699 Fax + 45 7027 1899 Firmaordninger I firmaoversigten kan du holde styr på dit kundekartotek samt disses bookinger. Der kan desuden oprettes andre firmaer end dit eget. Herved kan der udbydes særlige ydelser på med egne arbejdstider.

Læs mere

Rapport dannet den: 5. oktober 2010 1 Spil kontrol

Rapport dannet den: 5. oktober 2010 1 Spil kontrol 1 Spil kontrol kan vindes af 1 Jackpot - Identifikation - Gevinst - TotalGevinst - DatoTid - KommissionRake Spil - Identifikation - KøbDatoTid - Salgskanal - ForventetSlutDatoTid - FaktiskSlutDatoTid -

Læs mere

Fakturalinjeeksport Vejledning

Fakturalinjeeksport Vejledning Fakturalinjeeksport Spar tid og undgå at indtaste bogførte fakturaer manuelt i økonomisystemet Vejledning Kom godt i gang med fakturalinjeeksport Dette dokument beskriver TimeLog Projects eksportfunktion

Læs mere

Navision Stat 7.0. CVR Integration. Overblik. Side 1 af 15. 30. april 2015 ØS/ØSY/MAG

Navision Stat 7.0. CVR Integration. Overblik. Side 1 af 15. 30. april 2015 ØS/ØSY/MAG Side 1 af 15 Navision Stat 7.0 30. april 2015 ØS/ØSY/MAG CVR Integration Overblik Introduktion I denne vejledning kan du læse om, hvordan du validerer dine debitorers og kreditorers data op imod Det Centrale

Læs mere

How to do in rows and columns 8

How to do in rows and columns 8 INTRODUKTION TIL REGNEARK Denne artikel handler generelt om, hvad regneark egentlig er, og hvordan det bruges på et principielt plan. Indholdet bør derfor kunne anvendes uden hensyn til, hvilken version

Læs mere

BAAN IVc. Brugervejledning til BAAN Data Navigator

BAAN IVc. Brugervejledning til BAAN Data Navigator BAAN IVc Brugervejledning til BAAN Data Navigator En udgivelse af: Baan Development B.V. P.O.Box 143 3770 AC Barneveld Holland Trykt i Holland Baan Development B.V. 1997. Alle rettigheder forbeholdes.

Læs mere

Kort og godt om test af arkiveringsversioner

Kort og godt om test af arkiveringsversioner Kort og godt om test af arkiveringsversioner Data og dokumenter fra den offentlige forvaltnings it-systemer, som skal bevares for eftertiden, skal afleveres til arkiv i form af arkiveringsversioner. Arkiveringsversioner

Læs mere

5. OPSÆTNING DOKUMENTSKABELONER 5.1 TRIN

5. OPSÆTNING DOKUMENTSKABELONER 5.1 TRIN 5. OPSÆTNING DOKUMENTSKABELONER Under fanen Dok. skabeloner kan du arbejde med de skabeloner som du har i systemet, eller du kan oprette nye. I denne vejledning kigger vi på hvordan du kan tilrette selve

Læs mere

Bilag d. SYSTEMDOKUMENTATION til Inventarsystemet MS Access løsning

Bilag d. SYSTEMDOKUMENTATION til Inventarsystemet MS Access løsning Bilag d. SYSTEMDOKUMENTATION til Inventarsystemet MS Access løsning Maj 2004 Indholdsfortegnelse RELATIONER MELLEM TABELLER...4 TABELLER...5 INSTITUTIONSOPLYSNINGER...5 INVENTAR...10 INVENTARKODER...19

Læs mere

Daglig brug af JitBesked 2.0

Daglig brug af JitBesked 2.0 Daglig brug af JitBesked 2.0 Indholdsfortegnelse Oprettelse af personer (modtagere)...3 Afsendelse af besked...4 Valg af flere modtagere...5 Valg af flere personer der ligger i rækkefølge...5 Valg af flere

Læs mere

PORTFOLIO Version 2.0

PORTFOLIO Version 2.0 Nikolaj Lisberg Hansen Løsningsarkitekt og partner nikolaj.hansen@empisto.dk Tlf. 22 90 91 22 PORTFOLIO Version 2.0 Kvalitetsstyring med sags og dokumenthåndtering Teknisk revision af energimærker Portfolio

Læs mere

Multi kanal GSM porttelefon med adgangs kontrol

Multi kanal GSM porttelefon med adgangs kontrol Multi kanal GSM porttelefon med adgangs kontrol Model: MCI-3000V1 Funktioner: Metal tastatur. Robust anti-vandal enhed. Rustfrit stål dørstation. Nem installation kun fire ledninger. Anti-Vandal højttaler

Læs mere

Experian for Microsoft Dynamics Opsætningsvejledning

Experian for Microsoft Dynamics Opsætningsvejledning Experian for Microsoft Dynamics Opsætningsvejledning Indhold 1. Opsætningsvejledning... 3 1.1 Formål... 3 1.2 Forudsætninger... 3 1.3 Vigtigt... 3 2. Brugeropsætning... 4 2.1 Definering af brugeropsætning...

Læs mere

VEJDIREKTORATET. Vejdirektoratet DANBRO+ Modul 2 / Undermodul 2.3. DANBRO+ Forvaltningsmanual. Modul 2.3. Adresse- og telefonlister

VEJDIREKTORATET. Vejdirektoratet DANBRO+ Modul 2 / Undermodul 2.3. DANBRO+ Forvaltningsmanual. Modul 2.3. Adresse- og telefonlister Side: 1 af 11 VEJDIREKTORATET DANBRO+ Modul 2.3 Indholdsfortegnelse 1. INDLEDNING 3 2. FORMÅL OG ANVENDELSE 4 3. TEKNISK BESKRIVELSE INPUT AF DATA 4 3.1 Generelt 4 3.2 Adresse- og telefonlisten 4 3.3 Maillister

Læs mere

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING 2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING Baggrund Udgangspunktet er projekt 2, dvs. en blog om cupcakes, hvor målgruppe, afsender og modtager allerede er defineret. Du bliver nu bedt om at udvikle et

Læs mere

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1 Copyright: Naddon version 201009

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Klassisk. Side 1 Copyright: Naddon version 201009 Markedsinfo Microsoft Dynamics NAV 2009 SP1 Klassisk Side 1 Microsoft Dynamics NAV 2009 SP1 Rollebaseret Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller i

Læs mere

Spiller / Pårørende manual Til www.kampseddel.dk

Spiller / Pårørende manual Til www.kampseddel.dk Spiller / Pårørende manual Til www.kampseddel.dk Brugervejledning for Spiller/Pårørende Kort om kampseddel.dk Kampseddel.dk er udarbejdet som et webbaseret værktøj til den frivillige Træner/Leder i en

Læs mere

Document Capture for Microsoft Dynamics NAV. Ændringslog og opgraderingsnoter version 3.01

Document Capture for Microsoft Dynamics NAV. Ændringslog og opgraderingsnoter version 3.01 Document Capture for Microsoft Dynamics NAV Ændringslog og opgraderingsnoter version 3.01 INDHOLDSFORTEGNELSE Generelle ændringer... 3 Klassisk Klient... 5 Rollebaseret klient & server... 6 Webgodkendelse...

Læs mere

Rejsekort A/S idekonkurence Glemt check ud

Rejsekort A/S idekonkurence Glemt check ud Rejsekort A/S idekonkurence Glemt check ud 9. marts 2015 1 Indhold 1 Introduktion 4 1.1 Problembeskrivelse........................ 4 1.2 Rapportens opbygning...................... 4 2 Ordliste 5 3 Løsning

Læs mere

Vejledning for annoncering

Vejledning for annoncering Side 1 Denne vejledning indeholder oplysninger til brug ved annoncering på Aller Media A/S ( Aller ) prisportaler, EDBpriser.dk, DVDpriser.dk, HIFIpriser.dk, SPILpriser.dk og PRISER.dk. Vejledningen har

Læs mere

TimeLog A/S. TimeLog Project. Standardfakturalinjeeksport. Thomas S. Gudmandsen. w w w. t i m e l o g. d k

TimeLog A/S. TimeLog Project. Standardfakturalinjeeksport. Thomas S. Gudmandsen. w w w. t i m e l o g. d k TimeLog A/S TimeLog Project Standardfakturalinjeeksport Thomas S. Gudmandsen 2012 w w w. t i m e l o g. d k Indholdsfortegnelse TimeLog Standardfakturalinjeeksport Indledning... 2 Forudsætninger... 2 Opsætning...

Læs mere

Bookingsystem til hoteller. JTA-Data Jylland JTA. Vinkelvej 108a 8800 Viborg Tlf. 86672024 www.jta-data.dk DATA. Jylland

Bookingsystem til hoteller. JTA-Data Jylland JTA. Vinkelvej 108a 8800 Viborg Tlf. 86672024 www.jta-data.dk DATA. Jylland Bookingsystem til hoteller -Data: C5 bookingsystem til hoteller Indhold 1. Daglig brug af bookingsystemet. 2. Ny booking et værelse 3. Ny booking flere værelser 4. Ankomst 5. Rengøring 6. Afrejse 7. Værelsesoversigt

Læs mere

ECHNO. Techno-Webshop. Quick-Start. Techno Webshop - Din indgang. Fra marts 2011 er din indgang til Techno Webshoppen via vores hjemmeside.

ECHNO. Techno-Webshop. Quick-Start. Techno Webshop - Din indgang. Fra marts 2011 er din indgang til Techno Webshoppen via vores hjemmeside. Techno Webshop - Din indgang ECHNO Techno-Webshop Quick-Start Fra marts 2011 er din indgang til Techno Webshoppen via vores hjemmeside. www.techno-dk.dk 15 TECHNO Danmark Baldershøj 24 C, 1. sal 2635 Ishøj

Læs mere

SYSTEM DESIGN. 18. december 2012 [Mink Farm Rapport] Dette projekt bruger UP model, som er et krav for dette semesters projekt.

SYSTEM DESIGN. 18. december 2012 [Mink Farm Rapport] Dette projekt bruger UP model, som er et krav for dette semesters projekt. SYSTEM DESIGN Dette projekt bruger UP model, som er et krav for dette semesters projekt. Unified Process (UP) er en iterativ og gradvis softwareudvikling proces ramme, der bruges til at modellere hvad,

Læs mere

Mikkel Skovs hjemmeside Ledervedlejning

Mikkel Skovs hjemmeside Ledervedlejning Mikkel Skovs hjemmeside Ledervedlejning Version 1.1 10/08/2008 Indhold Indledning...1 Åbningsside...2 Login...5 Leder Info...5 Oprettelse af indhold...5 Oprettelse af artikel...5 Gem artikel...11 Hvem

Læs mere

Administrator v1.0 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk

Administrator v1.0 QUICK GUIDE. Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk Administrator v1.0 QUICK GUIDE Green Glass Software V/ Dan Feld-Jakobsen Lojovej 1 6200 Aabenraa 51 92 83 58 / dan@rekvi-skole.dk INTRODUKTION TIL REKVI-KONTOR Ideen med Rekvi-Kontor systemet udsprang

Læs mere

Profilhåndtering. Unifaun Online 2014-05-07

Profilhåndtering. Unifaun Online 2014-05-07 Profilhåndtering Unifaun Online 2014-05-07 2 Indhold 1 Profilhåndtering... 3 2 Centrale begreber i Profilhåndtering... 4 3 Administratoren... 6 4 Et eksempel - Blomster A/S... 7 5 Sådan opsættes profilhåndtering

Læs mere

Datatransport... 2. Import & Eksport af data... 2. Generelt... 2. Import/eksport... 4. Felter i Import og Eksport... 5

Datatransport... 2. Import & Eksport af data... 2. Generelt... 2. Import/eksport... 4. Felter i Import og Eksport... 5 Indhold Datatransport... 2 Import & Eksport af data... 2 Generelt... 2 Import/eksport.... 4 Felter i Import og Eksport... 5 Trykknapper til Import og Eksport... 7 1 Alle... 7 2 Slet... 7 3 Editor... 7

Læs mere

Adgang til eksterne referencedata, integration til egne systemer og søgning i egne kundedata som en samlet Master Data Management (MDM) løsning.

Adgang til eksterne referencedata, integration til egne systemer og søgning i egne kundedata som en samlet Master Data Management (MDM) løsning. idq MDM Edition Adgang til eksterne referencedata, integration til egne systemer og søgning i egne kundedata som en samlet Master Data Management (MDM) løsning. Hvad er Master Data Management? Master Data

Læs mere

Overførsler til udlandet

Overførsler til udlandet Danske Bank, Statens Betalinger Overførsler til udlandet Juli 2010 Side 1 Indhold 1 Indledning... 3 2 Krav til STP-betalinger indenfor EU:... 3 3 Krav til STP-betalinger udenfor EU:... 3 4 BIC (SWIFT)...

Læs mere

3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015

3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015 PROJECT DATABASE 3. SEMESTER 2. PROJECT MULB Gruppe 1. 20. september 2015 Ved at underskrive dette dokument bekræfter vi, at det indsendte materiale alt sammen er vores eget materiale og arbejde. Andreas

Læs mere

PHP kode til hjemmeside menu.

PHP kode til hjemmeside menu. PHP kode til hjemmeside menu. Home Hovedmenu 1 Hovedmenu 2 Hovedmenu 3 Hovedmenu 4 Undermenu 1 Breadcrumb Her vises indholdet af den valgte side Undermenu 2 Undermenu 3 Undermenu 4 Evt. en mulighed for

Læs mere

Hvad er et tal? Dan Saattrup Nielsen

Hvad er et tal? Dan Saattrup Nielsen 12 Det filosofiske hjørne Hvad er et tal? Dan Saattrup Nielsen Det virker måske som et spøjst spørgsmål, men ved nærmere eftertanke virker det som om, at alle vores definitioner af tal refererer til andre

Læs mere

Brugervejledning til Højkvalitetsdokumentationen og Dialogforummet på Danmarks Statistiks hjemmeside

Brugervejledning til Højkvalitetsdokumentationen og Dialogforummet på Danmarks Statistiks hjemmeside Brugervejledning til Højkvalitetsdokumentationen og Dialogforummet på Danmarks Statistiks hjemmeside Forord Denne vejledning beskriver baggrunden for begreber og sammenhænge i Danmarks Statistiks dokumentationssystem

Læs mere

Søren Løbner (lobner) ddb Databaser 2007 10 10

Søren Løbner (lobner) ddb Databaser 2007 10 10 ddb Excercise Week 4 Fra relationships til relations Nu når vi har fået vores skemaer på plads, kan SQL udtrykkene til konstruktion af relationerne laves Det foregår ved at vi tager en 1 til 1 oversættelse

Læs mere

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Rollebaseret. Side 1 Copyright: Naddon version 201009

Markedsinfo. Microsoft Dynamics NAV 2009 SP1 Rollebaseret. Side 1 Copyright: Naddon version 201009 Markedsinfo Microsoft Dynamics NAV 2009 SP1 Rollebaseret Side 1 Microsoft Dynamics NAV 2009 SP1 Rollebaseret Indholdet i dette dokument må på ingen måde gengives helt eller delvist hverken på tryk eller

Læs mere

Hold kontakten med dit netværk!

Hold kontakten med dit netværk! Hold kontakten med dit netværk! - Outlook er dit netværksprogram Outlook er mere end blot et mailprogram Du kan bruge Outlook til meget mere end blot at sende og modtage mails med. Eksempelvis, så er Outlook

Læs mere

Svea KundeWeb Brugervejledning. Svea Inkasso Version 1.1

Svea KundeWeb Brugervejledning. Svea Inkasso Version 1.1 Svea KundeWeb Brugervejledning Svea Inkasso Version 1.1 Indholdsfortegnelse 1. Brugervejledning... 3 Sektion 1.01 - Browser... 3 Sektion 1.02 Login... 3 Sektion 1.03 - Forside billede... 4 Sektion 1.04

Læs mere

GeoEnviron Web-løsninger

GeoEnviron Web-løsninger 2012 Troels Kreipke 01-01-2012 Indhold Generelt... 3 Web-løsninger... 3 XML-firewall... 4 GeoEnviron_WebService... 4 Installation af web-løsninger uden brug af GeoEnviron_WebService... 5 GeoEnviron_WebService...

Læs mere

Object-Relational Mapping

Object-Relational Mapping Databaser for udviklere () Datamatiker TietgenSkolen Underviser: Allan Helboe 06-06-2010 Problemformulering Denne opgave er et forsøg på at beskrive problemerne der opstår ved anvendelsen af en relationel

Læs mere

Installationsvejledning Family Tree Maker

Installationsvejledning Family Tree Maker Side 1 af 10 Først og fremmest tillykke med din nye version, oversat til dansk af undertegnede. Håber du bliver lige så glad for alle dens muligheder, som så mange over hele verden er blevet det. Installation

Læs mere

Silkeborg Review Mine sider

Silkeborg Review Mine sider Silkeborg Review Mine sider Datagrundlag Det er vigtigt, at de informationer man viser kan hentes let (hurtigt) fra bibliotekssystemet eller Brønden. Det vil betyde rigtig meget for hastighed i præsentationen

Læs mere

Easy Guide i GallupPC

Easy Guide i GallupPC Easy Guide i GallupPC Version. 6.00.00 Gallup A/S Masnedøgade 22-26 DK 2100 København Ø Telefon 39 27 27 27 Fax 39 27 50 80 Indhold SÅDAN KOMMER DU I GANG MED AT ANVENDE GALLUPPC... 2 TILFØJELSE AF UNDERSØGELSER

Læs mere

1 KY-kontering 26.11.2013

1 KY-kontering 26.11.2013 1 KY-kontering... 2 1.1 Bevilling... 3 1.1.1 Attributter... 3 1.2 Økonomisk effektueringsplan... 3 1.2.1 Attributter... 4 1.3 Bevilget ydelse... 5 1.3.1 Attributter... 5 1.4 Bevillingsmodtager... 5 1.5

Læs mere

Plant nu - Høst senere

Plant nu - Høst senere 1 Plant nu - Høst senere Af Mohammed & Hussein 2014 Mohammed & Hussein. Alle rettigheder forbeholdes. Uautoriseret kopiering eller distribution af dette materiale i enhver form er strengt forbudt. Lovovertrædere

Læs mere

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England.

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England. Cookievejledningens Tekniske Guide Den tekniske guide beskriver fem skridt til overholdelse af cookiereglerne: 1. Fastlæggelse af webejendom 2. Undersøgelse af om der sættes cookies på hjemmesiden 3. Afgivelse

Læs mere

Introduktion til frontend

Introduktion til frontend Side 1 af 43 Introduktion til frontend Dette dokument beskriver kort, hvordan du bruger WeroShop frontend. Dette omfatter at sætte dig ind i varegrupper, producenter og produkter, filtrering af produkter,

Læs mere

poedit og oversættelse af sprogfiler

poedit og oversættelse af sprogfiler poedit og oversættelse af sprogfiler af Georg S. Adamsen WordPress.Blogos.dk 2009 http://kortlink.dk/wordpressblogosdk/6g38 1 af 11 14-04-2009 14:55 Jeg får af og til spørgsmål om, hvordan man bruger poedit,

Læs mere

My booking. Generelt. Forsiden. Version 9.0

My booking. Generelt. Forsiden. Version 9.0 My booking Version 9.0 System til at lave online bookinger, med mulighed for opdeling i grupper, forskellige booking typer, ændre layout indstillinger, status styring, sprogvalg samt en del mere, detaljer

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:

Læs mere

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

Projekt Database, Gruppe 4A. Projekt 1, 3. Semester D A T A B A S E. Klasse MulA13 Gruppenummer: A4 Projekt Database, Gruppe 4A 0 Projekt 1, 3. Semester D A T A B A S E Klasse MulA13 Gruppenummer: A4 Projekt Database, Gruppe 4A 1 Fakta-ark Klasse MulA13, Gruppenummer: A4 Gruppemedlemmer: Amalie Ardahl

Læs mere

Appendiks 6: Universet som en matematisk struktur

Appendiks 6: Universet som en matematisk struktur Appendiks 6: Universet som en matematisk struktur En matematisk struktur er et meget abstrakt dyr, der kan defineres på følgende måde: En mængde, S, af elementer {s 1, s 2,,s n }, mellem hvilke der findes

Læs mere

Brugervejledning for virksomheder

Brugervejledning for virksomheder Brugervejledning for virksomheder Indholdsfortegnelse 1 Hvad kan virksomheden bruge Praktikpladsen.dk til?... 2 2 Virksomhedens forside... 2 3 Rediger virksomhedsprofil... 3 3.1 Stamdata... 3 3.2 Øvrige

Læs mere

Ordrebehandling og fakturering

Ordrebehandling og fakturering Ordrebehandling og fakturering I Mamut Stellar dannes en ordre. Ved bogføring af ordren dannes fakturaen. Indholdsfortegnelse Ordre/tilbud/faktura... 1 Indtastning i ordrehovedet... 2 Indtastning af varelinjer

Læs mere

Indtagsbegrebet. Eks. på boring i kalk.

Indtagsbegrebet. Eks. på boring i kalk. Indtagsbegrebet Indtag er et stykke af boringen, som indeholder et eller flere filtre. Det er det sted hvor vandet løber til/ind i boringen og/eller det sted, hvorfra der bliver taget vandprøver. Et indtag

Læs mere

1. Oprettelse 1.1 Salgsordre menu åbnes - klik på Salgsordrer. 1.2 Ny salgsordre oprettes. Kunde vælges ved at højreklikke på felt med kundenr.

1. Oprettelse 1.1 Salgsordre menu åbnes - klik på Salgsordrer. 1.2 Ny salgsordre oprettes. Kunde vælges ved at højreklikke på felt med kundenr. Oprettelse af en salgsordre og faktura 1. Oprettelse 2. Redigering/ændringer i låst salgsordre 3. Filtrering/sortering af salgsordrer 4. Afsendelse og fakturering 1. Oprettelse 1.1 Salgsordre menu åbnes

Læs mere

Kontakthierarkier i Digital Post

Kontakthierarkier i Digital Post Kontakthierarkier i Digital Post Denne vejledning beskriver forskellige måder myndigheder kan opbygge den kontaktbrugergrænseflade der møder slutbrugerne i Digital Post Version: 3. Udarbejdet: juli 2015

Læs mere

Kom i gang med... Kapitel 11 Math: Formelredigering med OpenOffice.org. OpenOffice.org

Kom i gang med... Kapitel 11 Math: Formelredigering med OpenOffice.org. OpenOffice.org Kom i gang med... Kapitel 11 Math: Formelredigering med OpenOffice.org OpenOffice.org Rettigheder Dette dokument er beskyttet af Copyright 2005 til bidragsyderne som er oplistet i afsnittet Forfattere.

Læs mere

Salgsprocessen i Navision. Registrering af salgsfaktura og klarmelding.

Salgsprocessen i Navision. Registrering af salgsfaktura og klarmelding. Salgsprocessen i Navision Registrering af salgsfaktura og klarmelding. ADMIEKP 20 03 2009 Indholdsfortegnelse 1 Salgsfakturering ikke elektronisk faktura 3 1.1 Fanebladet Generelt 4 1.1.1 Sælgerkode 5

Læs mere

Mayianne Nøks Pedersen www.mypedersen.dk/sem3projekt2databasewebsite.html Mail: mypedersen@gmail.com

Mayianne Nøks Pedersen www.mypedersen.dk/sem3projekt2databasewebsite.html Mail: mypedersen@gmail.com WEB & DATABASE 2. PROJEKT 3. SEMESTER Et projekt udarbejdet af studerende fra gruppe 1 klasse CL12mul3b11e: Elin Vatnhamar Olsen www.web324.webkn.dk/portfolio/websits.html Mail: elin.v.olsen@hotmail.com

Læs mere

GODDAG OG VELKOMMEN SOM KUNDE HOS DK HOSTMASTER

GODDAG OG VELKOMMEN SOM KUNDE HOS DK HOSTMASTER GODDAG OG VELKOMMEN SOM KUNDE HOS DK HOSTMASTER INDHOLDSFORTEGNELSE Hvem er dk hostmaster? 3 Hvad betaler du for? 3 Er der nogen i røret? 4 Hvad kan du, når du vil gøre det selv, på www.dk-hostmaster.dk?

Læs mere

Web MTC manual. Version 1.1 08-11-2012

Web MTC manual. Version 1.1 08-11-2012 Web MTC manual Version 1.1 08-11-2012 1 Revisioner: Version 1.0, 11-10-2012: Oprettelse af dokument Version 1.1, 08-11-2012: Afsnit om udskrivning af rapport tilføjet. 2 Indhold Sideopbygning... 5 Startside...

Læs mere

Sådan kommer du i gang med boldnettet

Sådan kommer du i gang med boldnettet Sådan kommer du i gang med boldnettet Man skal yde før man kan nyde... Sådan er det også med boldnettet. Jeres fodboldside er som start en skabelon hvor i skal fylde informationer i for at få glæde af

Læs mere