Obbligatorisk oppgave 2 Slektsdatabase 5602 Databaser Gruppenavn LEK Lars-‐Martin Hejll Eirik Simensen Krister Moen 113495 113452 113055 H2011
Oppgave 1 Begrepsmessig datamodell (E/R-‐diagram) E/R-‐ Diagram Physical modell For bedre oppløsning og størrelse se vedlagt filer E/R-‐Diagram.jpg, PD-‐E/R-‐
Diagram.jpg og E/R-‐modell.cdm Forretningsregler: 1) Alle personopplysninger er begrenset til mellom 1500 og 1900-‐tallet I oppgaveteksten er det oppgitt at det er lite sannsynlig at personer født før 1500 er nevnt i norske kirkebøker. Direktør Emanual Desperados har gitt føringer for at det ikke skal være mulig å registrer personer født etter 1900 av personvernhensyn. 2) Dødfødt i Begravelse tabell skal være Boolean (YES/NO) Default verdi No 3) Kjønn i person tabell, lovlige verdier: Mann eller Kvinne 4) Obligatoriske felter. Færrest mulig for å godta evt. mangefulle/svake opplysninger. Forutenom primærnøkler er Kjønn, fornavn, etternavn, fødselsdato og fødested (livskonstanter som alltid er tilgjengelige) satt til obligatoriske felter. (vi redigerte til dette etter importering til access. 5) Personnummeret skal være 1,3,5,7 eller 9 for kvinner og 2,4,6,8, eller 0 for menn. 6) Sivilstatus har kun fire betegnelser "ugift", "gift", "enke" og "enkemann" 7) I tabellen Begravelse skal PNR_Far oppgis vis den døde er et barn (18år) og PNR_Brud/brudgom oppgis som verge vis den døde var gift. 8) Dødsdato mindre enn begravelsesdato 9) Konfirmasjonsdato minst 12 år større en fødselsdato 10) Fødselsdato mindre en dødsdato 11) Fødselsdato mindre en dåpsdato 12) Barns fødselsdato minst 15 år større enn foreldrenes fødselsdato 13) Oppdatere sivilstatus og nytt bosted etter at en vielse er registrert 14) Innhenting av Pnr_Far og Pnr_Mor (Pnr_Verge) automatisk når PNR blir registrert ved hendelsene Konfirmasjon, Dåp og begravelse. Oppgave 2 Normalisering Vielse (VielseDato, VielseSted, ParretsNyeBosted, BrudgomFornavn, BrudgomEtternavn, Brudgom Fødselssted, Brudgom FødselsDato, Brudgom Bosted, Brudgom Sivilstatus, BrudFornavn, BrudEtternavn, BrudFødselssted, BrudFødselsdato, BrudBosted, BrudSivilstatus) Funksjonelle avhengigheter: BrudFornavn, BrudEtternavn , BrudgomFornavn, BrudgomEtternavn, VielsesDato à <alle kolonner> BrudFornavn, BrudEtternavn à BrudFødselsdato, BrudFødested BrudFornavn, BrudEtternavn, VielsesDato à BrudSivilstatus BrudFornavn, BrudEtternavn, VielsesDato à BrudBosted BrudgommFornavn, BrudgommEtternavn à BrudgommFødselsdato, Brudgomm Fødested BrudgommFornavn, BrudEtternavn, VielsesDato à BrudgommSivilstatus, BrudgommFornavn, BrudEtternavn, VielsesDato à BrudgommBosted BrudFornavn, BrudEtternavn, BrudgommFornavn, BrudgommEtternavn, Vielsesdato à Vielsessted BrudFornavn, BrudEtternavn, BrudgommFornavn, BrudgommEtternavn, Vielsesdato à Parrets nye Bo BrudFornavn, BrudEtternavn, BrudgommFornavn, BrudgommEtternavn, à VielsesDato Tabellstruktur: 2NF Ingen Anttributter er partielt avhengig av primærnøkkelen Vielse (VielseDato, VielseSted, BrudgomFornavn, BrudgomEtternavn, BrudFornavn, BrudEtternavn) Brud (Brudfornavn, BrudEtternavn, Brudfødselsdato, BrudFødested) Brudgomm (BrudgommFornavn, BrudgommEtternavn, BrudgommFødselsdato, BrudgommFødested) BrudBosted ( BrudFornavn, BrudEtternavn, VielsesDato, BrudBosted) BrudgommBosted (BrudgommFornavn, BrudgommEtternavn, VielsesDato, BrudgommBosted) BrudSivilstand (BrudFronavn, BrudEtternavn, Vielsesdato, BrudSivilstan BrudgommSivilstand ( BrudgommFornavn, BrudgommEtternavn, Vielsesdato, BrudgommSivilstand) Parets ”nye” bosted ( BrudFornavn, BrudEtternavn, BrudgommFornavn, BrudgommEtternavn, Parets ”nye” Bosted) Tabellstruktur: B/C med fornuftig utforming Vielse ( VielseDato, VielseSted, BrudFornavn* BrudEtternavn*, BrudgommFornavn*, BrudgommEtternavn*) Person (Fornavn, Etternavn Fødselsdato, Fødested) Bosted (Dato, Fornavn*, Etternavn*, Bosted) Sivilstand (Dato, Fornavn*, Etternavn*, Sivilstand) Burd og Brudgomm kunne med fordel bli identifisert med PersonNr. Sted kunne med fordel bli fremednøkkel mot en sted tabell. Dette ville ført til en slik tabell: Vielse ( Dato, Sted, BrudPNr*, BrudgommPNr*) PNr (PNr, Fornavn, Etternavn, Fødselsdato, Fødested) Bosted (Dato, PNr*, Sted) Sivilstand (Dato, PNr*, Sivilstand) Oppgave 3 Access-‐database Indekser: Vi oprette Indekser i tabellen Person i atributtene Fornavn og Etternavn. Vi indeksert disse atributtene for å gjøre person søkefunksjonen mer effektiv. Vi tillot duplisering med tanke på at fler personer kan ha det samme navnet. Forretningsregler: 1) 2) 3) Alle personopplysninger er begrenset til mellom 1500 og 1900-‐tallet >=#01.01.1500# And <#01.01.1900# I oppgaveteksten er det oppgitt at det er lite sannsynlig at personer født før 1500 er nevnt i norske kirkebøker. Direktør Emanual Desperados har gitt føringer for at det ikke skal være mulig å registrer personer født etter 1900 av personvernhensyn. Dødfødt i Begravelse tabell Is Not Null Or "No" Or "Yes" Default verdi er her satt til No Kjønn i person tabell (lovlige verdier) Is Not Null Or "Mann" Or "Kvinne" 4) 5) 6) 7) 8) 9) 10) 11) 12) 13) 14) Obligatoriske felter. Færrest mulig for å godta evt. mangefulle/svake opplysninger. Forutenom primærnøkler er Kjønn, fornavn, etternavn, fødselsdato og fødested (livskonstanter som alltid er tilgjengelige) satt til obligatoriske felter. Personnummeret skal være 1,3,5,7 eller 9 for kvinner og 2,4,6,8, eller 0 for menn. IIf(([Kjønn]="Mann");[PNR] Mod 2=1;IIf(([Kjønn]="Kvinne");[PNR] Mod 2=0)) Sivilstatus har kun fire betegnelser "ugift", "gift", "enke" og "enkemann" Is Null Or "gift" Or "ugift" Or "enke" Or "enkemann" I tabellen Begravelse skal PNR_Far oppgis vis den døde er et barn (18år) og PNR_Brud/brudgom oppgis som verge vis den døde var gift. (lot seg ikke implementere) Dødsdato mindre enn begravelsesdato (lot seg ikke implementere) Konfirmasjonsdato minst 12 år større en fødselsdato (lot seg ikke implementere) Fødselsdato mindre en dødsdato (lot seg ikke implementere) Fødselsdato mindre en dåpsdato (lot seg ikke implementere) Barns fødselsdato minst 15 år større enn foreldrenes fødselsdato (lot seg ikke implementere) Oppdatere sivilstatus og nytt bosted etter at en vielse er registrert (lot seg ikke implementere) Innhenting av Pnr_Far og Pnr_Mor (Pnr_Verge) automatisk når PNR blir registrert ved hendelsene Konfirmasjon, Dåp og begravelse. (lot seg ikke implementere) En fellesnevner for noen av de forretningsreglene som ikke lot seg implementere, grunner i at kolonnene betingelsene strekker seg over flere tabeller. Valg i forbindelse med generering av databasen • Vi valgte å samle alle livskonstanter i tabellen Person. Her samlet vi i tillegg informasjon om foreldre ved hjelp av egenkoplinger. • Det ble opprettet fire entiteter for de fire forskjellige hendelsene, Dåp, konfirmasjon, Vielse og begravelse. Hendelsen flytting implementerte vi ved hjelp av entiteten Bosted, som igjen er en svak entitet mot entiteten Person. På denne måten fikk vi også tilknyttet den tidsvarierende opplysningen, bosted mot person. • For den tidsvarierende opplysningen sivilstand (Eksteskapelig status) ble det opprette en svak entitet (sivilstand) mot entiteten person. Vi har ikke åpnet for skilsmisse, men har tillat fornyelse av ekteskap. • Vi opprettet to entiteter (Sted og Matrikkel) for å definere sted, ved en hendelse og ved flytting/bosted. Entiteten Matrikkel er svak mot entiteten Sted. •
I tabellen Begravelse opprettet vi attributten P.nrVerge for å være fleksibel for både ektefelle og far. Øvrige oppgaver Oppgave1 Vi startet utviklingen av den begrepsmessige datamodellen med penn og papir og satt opp ulike forslag til entiteter og attributter. Vi oppdaget fort at informasjonen ble omfattende. Vi byttet ut penn og papir med tavle og kritt slik at hele ER-‐Modellen ble vist på en tavle. På denne måten ble det mer oversiktlig og hele gruppen kunne delta med innspill. Når modellen begynte å bli ferdigstilt, overførte vi modellen til Power Designer. I Power Designer møtte vi utfordringer med tanke på relasjoner. Disse utfordringene førte til at vi flere ganger måtte vende tilbake til tavlen. Etter flere forsøk (9) ble vi fornøyd med modellen. Oppgave 2 På denne oppgaven valgte vi også å bruke tavle, for å få oversikt over tabellen Vielse som var utgangspunktet. Vi startet med å definere alle mulige avhengigheter utfra tabellen Vielse. Vi oppdaget at tabellen inneholdt flere funksjonelle avhengigheter og ingen transitive avhengigheter. Normaliseringsprosessen ble startet ved 2NF, og så over til Boyce-‐Codd normalform med en mer “fornuftig” utforming. Vi forbeholdt oss retten til å endre noen attributter og entiteter for å optimalisere tabellen. Oppgave 3 Se “ Valg i forbindelse av generering av databasen” Oppgave 4 I Access-‐applikasjonen valgte vi først å lage en hoved-‐meny. I hovedmenyen opprettet vi knapper for å registrere hendelsene Dåp, Konfirmasjon, Vielse og Begravelse. I tillegg laget vi en knapp “Personer” som åpner en ny meny, hvor en ny person kan legges til, slettes, endres eller søkes etter. Det ble opprettet en knapp for forhåndsvisning og utskrift av en kirke rapport som viser alle hendelser som har foregått i en spesiell Kirke. Bruker skriver her inn fra dato og til dato for de ulike hendelsenene som har forgått i en kommune i en spesiell Kike. Til slutt ble det opprettet en “Avslutt knapp” for å avslutte Access. For at Sindre skal kunne briljere med en utlegning om sub typer og makro programmering på den årlige høstgrøtfesten i binge lokalet på krok-‐ryggen, la vi med en kort innføring i dette (PDF/Latex).