Methods and models Anne Randorff Højen

Agenda Performance Normalisering og normalformer Pause Indexering

Performance

Performance Hvad er performance? Hvad kan påvirke performance?

Performance When you design a database, you must make sure that the database performs all the important functions correctly and quickly. Some performance issues can be resolved after the database is in production. However, other performance issues may be the result of a poor database design and can be addressed only by changing the structure and design of the database. When you design and implement a database, you should identify the large tables in the database and the more complex processes that the database will perform. You should also give special consideration to performance when you design these tables. Additionally, you should consider the effect on performance by increasing the number of users who can access the database. When you design a database, you must make sure that the database performs all the important functions correctly and quickly. Some performance issues can be resolved after the database is in production. However, other performance issues may be the result of a poor database design and can be addressed only by changing the structure and design of the database. When you design and implement a database, you should identify the large tables in the database and the more complex processes that the database will perform. You should also give special consideration to performance when you design these tables. Additionally, you should consider the effect on performance by increasing the number of users who can access the database. Examples of design changes that improve performance include the following: If a table that contains hundreds of thousands of rows must be summarized for a daily report, you can add a column or columns to the table that contains previously aggregated data to be used only for the report. Databases can be over-normalized. This means the database is defined with several, small, interrelated tables. When the database is processing the data in these tables, the database must perform far more work to combine the related data. This additional processing can reduce the performance of the database. In these situations, denormalizing the database slightly to simplify complex processes can improve performance.

Performance optimering Examples of design changes that improve performance include the following: If a table that contains hundreds of thousands of rows must be summarized for a daily report, you can add a column or columns to the table that contains previously aggregated data to be used only for the report. Databases can be over-normalized. This means the database is defined with several, small, interrelated tables. When the database is processing the data in these tables, the database must perform far more work to combine the related data. This additional processing can reduce the performance of the database. In these situations, de-normalizing the database slightly to simplify complex processes can improve performance.

Normalisering

Normalisering

RHS – Informationsteknologi Normalisering Normalisering er en teknik til at forbedre et database-design, i forhold til at undgå vores dødsfjender: Redundans – at noget data forekommer mere end én gang Inkonsistens – at noget data er i modstrid med andet data RHS – Informationsteknologi

Normalisering Hvis man er en haj til database-design – og følger reglerne – vil man ofte ende med en normaliseret database uden at tænke over det… Normalisering er en slags ”sundhedstjek” af dit database-design

Normalformer Enhver tabel på BCNF er på 3NF, osv. BCNF 3NF 2NF 1NF

Tre grader af normalisering – første grad 1.Normalform Tabellen har en nøgle Alle tabellens poster er lige lange

Tre grader af normalisering – første grad Hvorfor skal en tabel have en nøgle? Hvis en tabel ikke har en nøgle, kan vi ikke vide hvad data egentlig refererer til (tvetydighed) Navn Spansk Fransk Dansk Maria 10 4 7 12

Tre grader af normalisering – første grad Hvorfor skal posterne være lige lange? For at undgå spild af plads Typisk struktur Nøglefelt Variabelt antal datafelter Giver en tabel med felter a la Navn, Fag1, Fag2, Fag3, Fag4,…

Tre grader af normalisering – første grad (før) Elevnavn Fag1 Fag2 Fag3 Fag4 Fag5 Fag6 Fag7 Ib Jensen DA TY IT EN Bo Søgård AF SP Anne Høgh JU Ikke alle poster er lige lange Elevnavn er ikke entydigt

Tre grader af normalisering – første grad Hvordan løser vi problemerne? Trin 1: Indfør en nøgle Inkludér nok felter til at nøglen er entydig Opfind selv nøgle, ofte et løbenummer Trin 2: Indfør ny tabel med fast længde Ofte ændres Nøgle, Fag1, Fag2,… til Nøgle, Fag (med mange poster)

Tre grader af normalisering – første grad (efter) Alle poster i tabellen er unikke Alle poster i tabellen har længde 3 Tabellen er nu på 1.normalform! Elevnummer Elevnavn Fag 1 Ib Jensen DA TY IT EN 2 Bo Søgård AF SP 4 JU …og så videre…

Tre grader af normalisering – anden grad 2.Normalform Tabellen er på 1.normalform Der må kun være et nøglefelt i hver tabel, der entydigt afgør indholdet af alle øvrige felter

Tre grader af normalisering – anden grad Hvad i alverden betyder ”Der må kun være et nøglefelt i hver tabel, der entydigt afgør indholdet af alle øvrige felter”!? Husk, at et nøglefelt kan være et enkelt felt, eller en kombination af felter Nogle informationer kan måske udpeges entydigt med mindre information end den nøglefeltet rummer…

Tre grader af normalisering – anden grad (før) I denne tabel er Elev-nummer og Fag nøgle – denne kombination er entydig Men Elevnavn udpeges jo entydigt af Elev-nummer alene! ”Spild” at gentage Elev-navn gang på gang Elevnummer Elevnavn Fag Timer 1 Ib Jensen DA 2 TY 3 IT EN 4 Bo Søgård AF SP JU …og så videre…

Tre grader af normalisering – anden grad Løsningen er oftest at lave nye tabeller, hvor den ”mindst mulige” nøgle bruges I eksemplet: Elevnavn udpeges entydigt af Elevnummer… så lav en tabel med kun Elevnummer som nøgle Elevnavn fjernes derfor fra den oprindelige tabel

Tre grader af normalisering – anden grad (efter) Elevnummer Fag Timer 1 DA 2 TY 3 IT EN 4 AF SP JU Elevnummer Elevnavn 1 Ib Jensen 2 Bo Søgård 3 Anne Høgh 4 Elevnummer -> Elevnavn (Elevnummer, Fag) -> Timer …og så videre…

3 grader af normalisering – tredje grad 3.Normalform Tabellen er på 2.normalform Alle felter, der afhænger af andet end nøgle-feltet, splittes ud i andre tabeller

3 grader af normalisering – tredje grad (før) Elevnummer Elevnavn Postnummer By 1 Ib Jensen 4100 Ringsted 2 Bo Søgård 4000 Roskilde 3 Anne Høgh 4 Elevnummer udpeger entydigt Elevnavn, Postnummer og By; d.v.s. 2.normalform OK MEN Postnummer udpeger også entydigt By!

3 grader af normalisering – tredje grad (efter) Elevnummer Elevnavn Postnummer 1 Ib Jensen 4100 2 Bo Søgård 4000 3 Anne Høgh 4 Postnummer By 4100 Ringsted 4000 Roskilde Elevnummer -> Elevnavn, Postnummer Postnummer -> By

Normalisering i en nøddeskal Normalisering skal fjerne redundans og inkonsistens fra databasen Vær på vagt, hvis samme information forekommer mange gange – er det nødvendigt…? Brug reglerne for normalisering som et ”sundhedscheck” for databasens design

Indexering

Index Beskriv med egne ord hvad I forstår med et index.

Indexering er en vigtig egenskab for databaseteknologier Muliggør effektiv søgning Øger DB-performance ... Kræver at man ved hvad man vil bruge data til!

Index 1 2 3 4 5 10 9 8 7 6

Index = 1,3,5,6,8,10 1 2 3 4 5 10 9 8 7 6

Index = 3,4,8,9 1 2 3 4 5 10 9 8 7 6

Index Ananas = Rum 1 Ananas = Rum 2 Ananas = Rum 6 Ananas = Rum 7 Banan = Rum 1 Banan = Rum 3 Banan = Rum 5 Banan = Rum 6 Banan = Rum 8 Vindruer = Rum 3 Vindruer = Rum 4 Vindruer = Rum 8 Vindruer = Rum 9 Æble = Rum 1 Æble = Rum 2 Æble = Rum 4 Æble = Rum 5 Æble = Rum 9 Æble = Rum 10 1 2 3 4 5 6 7 8 9 10