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

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

FamiliedatabaseProjektgruppe 1 efterår Analysefasen Marius Vestergaard

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

FamiliedatabaseProjektgruppe 1 efterår 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)

FamiliedatabaseProjektgruppe 1 efterår 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.

FamiliedatabaseProjektgruppe 1 efterår 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.

FamiliedatabaseProjektgruppe 1 efterår 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

FamiliedatabaseProjektgruppe 1 efterår 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

FamiliedatabaseProjektgruppe 1 efterår 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.

FamiliedatabaseProjektgruppe 1 efterår 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.

FamiliedatabaseProjektgruppe 1 efterår Designfasen Claus W. Jensen

FamiliedatabaseProjektgruppe 1 efterår 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

FamiliedatabaseProjektgruppe 1 efterår HasAddress n 1 n 1 n n FatherIs MotherIs PersIParttSk m n m n phone pId firstnames surname sex birthday death addressId district city country fileName street archType Subject partnerTyp e locality description phoneTyp e Type Address 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)

FamiliedatabaseProjektgruppe 1 efterår HasAddress n 1 n 1 n n FatherIs MotherIs PersIParttSk m n m n phone pId firstnames surname sex birthday death addressId district city country fileName street archType Subject partnerTyp e locality description phoneTyp e Type Address 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

FamiliedatabaseProjektgruppe 1 efterår HasAddress n 1 n 1 n n FatherIs MotherIs PersIParttSk m n m n phone pId firstnames surname sex birthday death addressId district city country fileName street archType Subject partnerTyp e locality description phoneTyp e Type Address 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) =(pId number references Person, Address string, Type 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

FamiliedatabaseProjektgruppe 1 efterår ”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) =(pId number references Person, Address string, Type 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)

FamiliedatabaseProjektgruppe 1 efterår 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.

FamiliedatabaseProjektgruppe 1 efterår 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

FamiliedatabaseProjektgruppe 1 efterår Implementering Peter Isager

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

FamiliedatabaseProjektgruppe 1 efterår 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 );

FamiliedatabaseProjektgruppe 1 efterår 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 ( pId int not null references Person, Address varchar(50), Type char (10), primary key (pId, Address) );

FamiliedatabaseProjektgruppe 1 efterår Oprettet tabellerRelationer mellem tabellerne

FamiliedatabaseProjektgruppe 1 efterår 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

FamiliedatabaseProjektgruppe 1 efterår 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.

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

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

FamiliedatabaseProjektgruppe 1 efterår 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

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

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

FamiliedatabaseProjektgruppe 1 efterår 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

FamiliedatabaseProjektgruppe 1 efterår 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