1 Familiedatabase Pilotprojekt for gruppe 1 Efterår 2005 Peter Isager - Claus W. Jensen - Marius Vestergaard - Benny Olesen - Jan Helbo.

Præsentationer af emnet: "1 Familiedatabase Pilotprojekt for gruppe 1 Efterår 2005 Peter Isager - Claus W. Jensen - Marius Vestergaard - Benny Olesen - Jan Helbo."— Præsentationens transcript:

1 1 Familiedatabase Pilotprojekt for gruppe 1 Efterår 2005 Peter Isager - Claus W. Jensen - Marius Vestergaard - Benny Olesen - Jan Helbo

2 FamiliedatabaseProjektgruppe 1 efterår 20052 Emneoversigt Præsentation og Analyse Marius Design Claus Implementering Peter Arbejdsprocessen Benny

3 FamiliedatabaseProjektgruppe 1 efterår 20053 Analysefasen Marius Vestergaard

4 FamiliedatabaseProjektgruppe 1 efterår 20054 Analyse Problemanalyse – formål Requirement Analysis - Information Flow Diagram System specification – Task Decomposition Task Form Navigationsdiagram (External Document) E-R Diagram (Conceptual Model)

5 FamiliedatabaseProjektgruppe 1 efterår 20055 Formålet med denne Familiedatabase at kunne registrere en families data med henblik på senere opslag at sikre registreringerne så det er muligt at få en historik inden for afgrænsede områder opslagene i familiens data skal kunne gennemføres via en Web-browser der skal kunne registreres nye familiemedlemmers data via en Web- browser der skal kunne udtrækkes data, der kan danne grundlag for opstilling af stamtræ for familien der skal kunne dannes lister (skærm og/eller papir) med data på enkeltpersoner der skal kunne dannes lister (skærm og/eller papir) med de familiemedlemmer der har fødsels- eller bryllupsdag i en given måned der skal kunne dannes lister (skærm og/eller papir) med data for familiens børn der skal kunne dannes lister (skærm og/eller papir) med data for familiens børnebørn der skal kunne dannes lister (skærm og/eller papir) med relevante data for familiens fætre og kusiner (også dem der er ”gift” ind i familien)

6 FamiliedatabaseProjektgruppe 1 efterår 20056 Requirement Analysis - Information Flow Diagram Informations Flow Diagrammet er en grafisk metode til at vise dataflowet i systemet. En alternativ metode kunne være brug af Use Case Diagram fra UML.

7 FamiliedatabaseProjektgruppe 1 efterår 20057 System specification – Task Decomposition ”Informations Flow Diagrammet” viser en overordnet opdeling af systemet. De enkelte tasks fra Informations Flow Diagrammet bliver ved Decomposition delt op i subtasks. Eksemplet viser task for inddata til systemet.

8 FamiliedatabaseProjektgruppe 1 efterår 20058 System specification – Task Decomposition Eksemplet her viser de subtasks der er tænkt til udtræk af persondata, lister og arkivalier (BLOBS). Et alternativ til Task Decomposition kunne være aktivitets- eller sekvensdiagrammer fra UML

9 FamiliedatabaseProjektgruppe 1 efterår 20059 Eksempel på en Task Form Task Form er en detaljeret beskrivelse af den enkelte Task. Input gør brug af et External Document, som beskriver brugerens interaktion med systemet. Et alternativ kunne være en Use Case Description i UML

10 FamiliedatabaseProjektgruppe 1 efterår 200510 Eksempel på et Navigationsdiagram ( Grafisk illustration af External Document) Et External Document beskriver brugerens interaktion med systemet (er ikke vist) En mere illustrativ måde at fremstille det på er at benytte et Navigationsdiagram, som vist her.

11 FamiliedatabaseProjektgruppe 1 efterår 200511 Entity – Relationship, E-R Diagram Analysefasen afsluttes med en Conceptuel Model – et E-R Diagram. Her ses alle Entitets klasser, Relationer og de Attributter der hører til Entiteterne. De attributter, der fungerer som primærnøgler, er understreget. Kardinaliteterne på de enkelte relationer er også vist.

12 FamiliedatabaseProjektgruppe 1 efterår 200512 Designfasen Claus W. Jensen

13 FamiliedatabaseProjektgruppe 1 efterår 200513 Translation and normalization Udarbejdelse af relationsskemaer Normalisering af tabellerne E-R diagram Translation of E-R diagram into a relational data model Normalization Redefine E-R diagram En iterativ proces Analyse Implementering Design

14 FamiliedatabaseProjektgruppe 1 efterår 200514 HasAddress n 1 n 1 n n FatherIs MotherIs PersIParttSk m n m n email phone pId firstnames surname sex birthday death addressId district city country fileName street archType Subject partnerTyp e locality description phoneTyp e emailType emailAddress mother father Person Archive Address addressTyp e phoneNumbe r dissolved formed Partnerskab psId Et relationsskema pr. entitetsklasse Skema=attributter Person=(pId number, firstnames string, surname string, sex string, birthday date, death string, mother number references Person, father number references Person) Partnerskab=(psId number, formed date, dissolved string, psType string) Address=(addressId number, street string, district string, city string, locality string, country string) Archive=(fileName string, archType string, description string) Først oprettes et skema for hver entitetsklasse, og der defineres hvilken eller hvilke attributter der skal udgøre nøglen for tabellen (jf. Rule no. 1)

15 FamiliedatabaseProjektgruppe 1 efterår 200515 HasAddress n 1 n 1 n n FatherIs MotherIs PersIParttSk m n m n email phone pId firstnames surname sex birthday death addressId district city country fileName street archType Subject partnerTyp e locality description phoneTyp e emailType emailAddress mother father Person Archive Address addressTyp e phoneNumbe r dissolved formed Partnerskab psId Many-to-many relationsship Skema=Indhold Person=(pId number, firstnames string, surname string, sex string, birthday date, death string, mother number references Person, father number references Person) Partnerskab=(psId number, formed date, dissolved string, psType string) Address=(addressId number, street string, district string, city string, locality string, country string) PersIPartSk=(pId number references Person, psId number references Partnerskab) Address=(addressId number, street string, district string, city string, locality string, country string) HasAddress=(pId number references Person, addressId number references Address, addressType string) Archive=(fileName string, archType string, description string) Subject=(pId number references Person, fileName string references Archive) For hver mange til mange relation oprettes et skema (jf. Rule no. 5), nøglerne i de relaterede entitetsklasser angives som ”foreign keys” i skemaet

16 FamiliedatabaseProjektgruppe 1 efterår 200516 HasAddress n 1 n 1 n n FatherIs MotherIs PersIParttSk m n m n email phone pId firstnames surname sex birthday death addressId district city country fileName street archType Subject partnerTyp e locality description phoneTyp e emailType emailAddress mother father Person Archive Address addressTyp e phoneNumbe r dissolved formed Partnerskab psId Multivalued attributes Skema=Indhold Person=(pId number, firstnames string, surname string, sex string, birthday date, death string, mother number references Person, father number references Person) Phone=(pId number references Person, phoneNumber string, phoneType string) Email=(pId number references Person, emailAddress string, emailType string) Partnerskab=(psId number, formed date, dissolved string, psType string) Address=(addressId number, street string, district string, city string, locality string, country string) For hver multivalued attribute oprettes et skema (jf. Rule no. 7), nøglerne i de relaterede entitetsklasser angives som ”foreign keys” i det nye skema

17 FamiliedatabaseProjektgruppe 1 efterår 200517 ”Færdige” relationsskemaer Skema=Indhold Person=(pId number, firstnames string, surname string, sex string, birthday date, death string, mother number references Person, father number references Person) Phone=(pId number references Person, phoneNumber string, phoneType string) Email=(pId number references Person, emailAddress string, emailType string) Partnerskab=(psId number, formed date, dissolved string, psType string) PersIPartSk=(pId number references Person, psId number references Partnerskab) Address=(addressId number, street string, district string, city string, locality string, country string) HasAddress=(pId number references Person, addressId number references Address, addressType string) Archive=(fileName string, archType string, description string) Subject=(pId number references Person, fileName string references Archive)

18 FamiliedatabaseProjektgruppe 1 efterår 200518 Normalisering Ved normalisering af tabellerne forstås en kvalitetskontrol af tabelstrukturen i databasen, således at fejl i databasen som følge af redundans i tabellerne undgås, og ligeledes reducere antallet af felter med evt. null værdier Beskrivelse af 3NF: Et relations schema er i Tredje Normal Form (3NF) såfremt alle funktions afhængigheder (Functional dependencies) enten har en supernøgle som determinant eller attributterne på højre side er nøgle attributter. Altså ved 3NF er ikke nøgle attributter funktionsmæssig bestemt udelukkende af nøgler eller supernøgler. Funktionsmæssige afhængigheder for tabellen ”Address” Address:(addressId number, street string, district number, city string, locality string, country string) FD5: addressId street, district, city, locality, country FD6: districtcity FD6 er en 3NF konflikt, men kun så længe vi ser på Danmark, da vi ønsker at databasen skal kunne bruges global ses der bort fra denne konflikt.

19 FamiliedatabaseProjektgruppe 1 efterår 200519 Translation and normalization Udarbejdelse af relationsskemaer Normalisering af tabellerne E-R diagram Translation of E-R diagram into a relational data model Normalization Redefine E-R diagram En iterativ proces Analyse Implementering Design

20 FamiliedatabaseProjektgruppe 1 efterår 200520 Implementering Peter Isager

21 FamiliedatabaseProjektgruppe 1 efterår 200521 Tabeldefinitioner –Create tables med SQL SQL forespørgsler WEB brugerflade med ASP og SQL

22 FamiliedatabaseProjektgruppe 1 efterår 200522 Tabeldefinitioner Person=(pId number, firstnames string, surname string, sex string, birthday date, death string, mother number references Person, father number references Person) Relationsskemaerne der blev udarbejdet efter normaliseringen bliver efterfølgende brugt til at lave tabeldefinitionerne. Create table Person( pId counter primary key, firstnames varchar(50) not null, surname varchar(30) not null, sex varchar(10) not null, birthday char(30), death char(30), mother int references Person, father int references Person );

23 FamiliedatabaseProjektgruppe 1 efterår 200523 1. Tabeller der oprettes ved brug af SQL, skal oprettes i rigtig rækkefølge for at undgå problemer med reference til fremmede nøgler. Eksempelvis kan nedenstående tabel ikke oprettes før tabellen Person pga referencen. 2. Efter oprettelse af en tabel tilrettes den i feltet valideringsregel Create table Email( pId int not null references Person, emailAddress varchar(50), emailType char (10), primary key (pId, emailAddress) );

24 FamiliedatabaseProjektgruppe 1 efterår 200524 Oprettet tabellerRelationer mellem tabellerne

25 FamiliedatabaseProjektgruppe 1 efterår 200525 Udvalgte SQL forespørgsler Denne select finder børn for en given person SELECT Person.pId As Far_pId, Child.pId As Barn_pId, Child.firstnames As Fornavn, Child.surname As Efternavn, Child.sex As Køn, Child.birthday As Fødselsdag, Child.death As Dødsdag FROM Person INNER JOIN Person AS Child ON Person.pId=Child.father WHERE Person.pId= Child.father And Person.pId=11 Efter implementering af tabellerne med forskellige forespørgsler som eksempelvis nedenstående. Specificerer attributter der præsenteres i den resulterende tabel Specificerer tabeller der vælges fra Specificerer betingelser for udvælgelse af data

26 FamiliedatabaseProjektgruppe 1 efterår 200526 WEB brugerflade med ASP og SQL HyperText Mark-up Language kode har vi brugt til at lave vores web interface Cascading Style Sheets har vi brugt i vores web interface til at styre layout centralt fra et style sheet. Gøres med en enkelt reference i html dokumentet. Active Server Pages har vi brugt på web server siden til at generere og udskrive data på baggrund af de data der bliver indtastet på klient siden SQL forespørgsler har vi brugt til at lave opslag i databasen på server siden.

27 FamiliedatabaseProjektgruppe 1 efterår 200527 Arbejdsprocessen ”Procesrapporten” Benny Burhøj Olesen

28 FamiliedatabaseProjektgruppe 1 efterår 200528 Procesrapporten Emner i rapporten er: Gruppearbejdet Anvendte redskaber Kommunikation Dokumenthåndteringen Konferencer Supervision Konklusioner

29 FamiliedatabaseProjektgruppe 1 efterår 200529 Gruppearbejdet Gruppearbejdet (Opstart - 9/10 sep. 2005) Grundlæggende arbejdsmodeller –alle et forslag til løsning –fordelt til bidrag fra enkeltpersoner Delprocesser –Mundtlige konferencer –Opdelte løsningsforslag –Samskrivning fulgt af kommentarer –Aftalt aflevering af produkt Brud i opgaveafklaring

30 FamiliedatabaseProjektgruppe 1 efterår 200530 Anvendte redskaber RedskabspaletAnvendelse UniflexGennemgående Asynkrone værktøjer e-mails NEWS-grupper Mere og mere (ej anvendt) Synkrone redskaber Skrive, tale, se Shared whiteboard Application sharing Skype (ej anvendt) Word, Access

31 FamiliedatabaseProjektgruppe 1 efterår 200531 Kommunikation og dokumenthåndtering Kommunikationen forløbet gnidningsfri –Dokumentudveksling via Uniflex –Dokumentudveksling mm. via e-mail –Mundtlig via Skype Småproblemer: E-mailadresser, filtyper Dokumenter: Alt via uniflex -> Sup. med mail –Problem m/ kommentarer – løst via reload Word (in line kommentarer)

32 FamiliedatabaseProjektgruppe 1 efterår 200532 Konferencer og Supervision Konferencer –Afholdt i alt 9 telefonkonferencer Planlægning og evt. rettelser –Dagsorden mm inden møderne –Flytninger aftalt via mail Opsummering –Klare aftaler om hvem der laver hvad –Aftalt deadlines for aflevering af materialer –Aftalt et næste møde. Supervision –Opstart og flere telefonmøder –Aftalt via mail

33 FamiliedatabaseProjektgruppe 1 efterår 200533 Konklusioner Generelle konklusioner –Opstartmødet fundament for senere arbejde –Krumtappen var: Øvelser og pilotprojekt –Tidligere projekterfaring = ingen problemer –Grundlag: Klare aftaler –Skype: Redskab, god kvalitet Gøres bedre –Langsigtet planlægning og ”klarhed” for alle –Fokus på andre kurser – uden øvelser