I4DAB1 F08 guideline for normalisering og design Take 2 Jesper Tørresø DAB1 F08 21. April 2008.

Slides:



Advertisements
Lignende præsentationer
Kundebetjening Opgave med salgstrappen.
Advertisements

Trin 1: Vand ind i ’Kassen’
Kan man gøre andre mennesker lykkelige?
Kan en Internet tilkoblet bruger sende en til andre Internet tilkoblede brugere uafhængig af hvilket operativsystem modtageren har? •Ja •Nej.
Innovative Værksteder til udvikling af Akademiuddannelserne IVA
Formularer (Access, del 3)
The Sims2 Double Deluxe + Sims 2 Pets
3. Funktionelle afhængigheder og normalisering
Problemliste Listen laves vilkårligt – herefter udvælges det problem der har 1. prioritet
Livets Ord Juni 2011 ”Og tilpas jer ikke denne verden, men lad jer forvandle, ved at sindet fornyes, så I kan skønne, hvad der er Guds vilje: det gode,
Sundhedsprofessionelles forståelser af patientinddragelse
Karl Henrik Flyums model
ER-diagrammer (databaser, del 4)
Usability – øvelse 2: Heuristisk inspektion
Økonometri 1: Specifikation og dataproblemer1 Økonometri 1 Specifikation, og dataproblemer 4. november 2005.
Målet for os i dag ”At lære jer en simpel model, der sætter jer i stand til, at opbygge en argumentation, der giver jeg gennemslagskraft”
NOEA/IT - FEN - Databaser/TabelDesign 1 Tabeldesign Design af relationsdatabaser Normalisering.
Oprettelse af tabeller (Access, del 2)
Samarbejde eksternt/Netværk Et inspirationsværktøj Det er ikke, hvad du ved, men hvem du kender, der tæller!
EVA’s evaluering af 10. klasse Foreningen af 10. klasseskoler i Danmark, Trinity, Fredericia den 2. marts 2012 Kristine Bang Nielsen.
2:Relations modellering og design regler.
SQL Introduktion Jesper Tørresø DAB1 F08 6. Februar 2008.
Relationsdatabaser og SQL
Økonometri 1: Specifikation og dataproblemer1 Økonometri 1 Specifikation, og dataproblemer 7. april 2003.
God læring God undervisning
SQL – Oracle Relationsdatabase
Normalisering (databaser, del 8)
Tema 6 Samvær og fælles aktiviteter
Min præsentation Varighed – ca. 3 minutter Vurdering af blog i 8 faser I dybden med 5 af faserne Formål.
Informationssystemer kursusgang: Modellering med henblik på dataudtræk
Spørgsmål 2: Relations modellering og designregler Gruppe 2.
AT 3.2 Igangsættelse af tankeprocesser – at udvælge endelig sag og formulere problemformulering.
Relationelle databaser og XML
SQL Jesper Tørresø DAB1 E oktober Punkter for i dag. SQL baggrund. Relationel algebra. Brug af VS2005.
Rapporter (Access, del 5). RHS – Informationsteknologi – Udgangspunkt Vi har oprettet en database Vi har defineret en eller flere tabeller, og.
OIM CSS Klassemodel | Side 1 OIM CSS-klassemodel-projektet Status pr. 9. april 2008: -version 0.9 af CSS-klassemodellen og et oplæg til revisionsprocessen.
2009NOEA/IT - Databaser/arkitektur1 Tabeldesign Design af relationsdatabaser Normalisering.
IT i Byggeriet Semester 6, kursusgang Databaser (2) Kjeld Svidt Kjeld Svidt  Institut for Bygningsteknik  Aalborg Universitet.
IT i Byggeriet Semester kursusgang Databaser (2) Kjeld Svidt Kjeld Svidt  Institut for Bygningsteknik  Aalborg Universitet.
Normalisering Sund Fornuft!. Normalformer 1. Normalform Ingen repeterende felter Der eksisterer en primær nøgle 2. Normalform Tabellen skal være i 1NF.
Introduktion I4DAB1 Jesper Tørresø Forår Layers + Tiers ? Tiers er opdelinbgslag omkring en logisk abstraktion (Præsentation, forretningslogik og.
Erhvervsøkonomi / Managerial Economics
Opslagsfelter (Access, del 6). RHS – Informationsteknologi – Udgangspunkt Vi er ofte i den situation, at valg af en type for et felt ikke begrænser.
Introduktion til Access (Access, del 1). RHS – Informationsteknologi – Fra design til udvikling Vi ved nu, hvordan vi finder et design for en database,
Intro Databaserne? Gik det som det skulle?. Databasestøttet webpublicering Forelæsning nr 8 Hvorfor data i en RDB (relationel database)? Databasemodellering.
3. Objekt Orientering og Relations Databaser
Kjeld Svidt  Institut for Byggeri og Anlæg  Aalborg Universitet IT i Byggeriet Semester 6, kursusgang Databaser (2) Kjeld Svidt
NOEA/IT FEN - Databaser/modellering 1 Datamodellering Den udvidede (enhanced) E/R-model (EE/R- modellen) Begreber Diagrammering Omformning til.
Økonometri 1: Specifikation og dataproblemer1 Økonometri 1 Specifikation og dataproblemer 2. november 2004.
SQL Jesper Tørresø DAB1 E September Punkter for i dag. SQL baggrund. Relationel algebra. SQL koncept –Vises ved brug af VS2008.
I4DAB1 F08 guideline for normalisering og design Jesper Tørresø DAB1 F April 2008.
Oprettelse af tabeller (Access, del 2)
Jörg ZellerFOL-modul31 Slutning: Logik som tænknings-model En hovedgrund for konstruktionen af et logisk sprog er at kunne give en præcis definition af.
DB analyse og modellering Jesper Tørresø DAB1 F Februar 2008.
Usability – øvelse 2: Heuristisk evaluering
Den relationelle model
Økonometri 1: F141 Økonometri 1 Specifikation og dataproblemer 6. november 2006.
KM2: F211 Kvantitative metoder 2 Specifikation og dataproblemer 30. april 2007.
Formularer (Access, del 3). RHS – Informationsteknologi – Udgangspunkt Vi har oprettet en database Vi har defineret en eller flere tabeller Vi.
Omsætning af en model til en RDB Jesper Tørresø DAB1 F Marts 2008.
Sanne Kjærgaard Nikolajsen FOA
TEMA 5 Realisering: Tilpas idéen
Videnskabeligt projekt
Efter Karl Henrik Flyums modeller
DB analyse og modellering
Titel-layout Undertitel.
Titellayout Undertitel.
Titel med billeder-layout
Titellayout Undertitel.
Titellayout Undertitel.
Præsentationens transcript:

I4DAB1 F08 guideline for normalisering og design Take 2 Jesper Tørresø DAB1 F April 2008.

2 F08’ opgave Opstil jeres egne formulerede guide lines for database normalisering og design Tag udgangspunkt i reglerne for 1NF-3NF, BCDNF og 4NF. Prøv at beskrive/vúdrere sammenhængen mellem databasedesign og normalisering. Inddrag kendte teknikkerne og prøv at beskrive/vurdere deres betydning.

3 Punkter for i dag. Er normalisering en ”Hund i et spil kegler”? Bruges designreglerne ? Mangles der nogle trin ? Designregler Normalisering ”Sandheden” Rigtige verdens model Bestemmer!!

4 Paradoks Et eksempel Udgangspunkt 4 Normalform 4NF Tildeling af projekter og opgaver til ansatte: –Ansatte kan tildeles hvilket som helst projekt og hvilken som helst opgave –Ansatte kan tildeles opgaver uanset opgaver i andre projekter –Et projekt og en opgave kan have et vilkårligt antal ansatte Det betyder altså at relationerne mellem ansat og opgaver, samt mellem ansat og projekt er M:M.

5 Paradoks

6

7 På grund af de 2 flerværdiede afhængigheder: –Ansatnr. ->> Projekttype –Ansatnr. ->> Opgavetype er der følgende problemer: Information om nye ansatte der skal arbejde på projekter, men endnu ikke er tildelt opgavetyper kan ikke registreres i tabellen Slettes en ansats projekttildeling slettes også information om vedkommendes mulige opgavetyper Skal der tilføjes information om en ansat og en opgavetype, skal der tilføjes flere rækker hvis han i forvejen er tilknyttet projekter. Det samme gælder for ændringer.

8 Paradoks

9 Paradoks ??? Hvordan ved vi nu hvilke opgave den ansatte udfører på et givent projekt ??? Kan i nu set paradokset 4NF….. Og hvad så, hvad siger den rigtige verden? Se nu [TEOREY] Kap 5 side 96. Ternary relationsship Og [TEOREY] Kap Side 127