her er lidt inspiration fra en større opgave på mit studie:
4. Database
Databasen som skal benyttes til produktet skal være en relationel mySQL database. Bindingen mellem produktet og databasen sker i dbHandler som afvikler alle SQL sætninger og opretter forbindelsen til mySQL databasen.
4.1. Kravspecifikation
4. Introduktion
4.1 Formål: Kravspecifikationen opstiller kravene til prototypen af vores database. Databasen er en vigtig del af hele produktet. Kravene skal fungere som grundlæggende accept af databasen. De skal endvidere udgøre en start til designfasen.
4.2 Databasen: Udvikles med henblik på at kunne bruges i produktet til JA forlaget A/S. De specifikke funktioner er beskrevet nærmere i punkt 3. Databasen udvikles med baggrund i den stillede opgave.
4.3 Definitioner: Definition på database: En delt samling af logisk sammenhængende data (samt beskrivelsen af disse), som er designet til at leve op til en organisations informationsbehov.
4.4 Overblik: Punkt 2 giver et indblik i systemets generelle egenskaber.
5. Generel beskrivelse
5.1 Databasens formål: Skal være en vigtig del af produktet og fungerer som et vigtigt element i det samlede produkt
5.2 Databasens funktioner: Databasens overordnede funktioner består af:
• Levering af data til produktet.
• Modtagelse af data produktet.
5.3 Brugere: Produktet. Det er kun det endelige produkt som benytter databasen.
6. Specifikke krav
6.1 Miljøkrav
6.1.1 Brugergrænseflade: Databasen styres fra produktet
6.2 Funktionelle krav
6.2.1 Funktioner til styring af databasen:
• Finde data
• Udvælge data
• Indsætte data
• Ændre data
• Returnere data
4.1.1. Krav til databasens konceptuelle design
Definition: Det fælles view af databasen. Dette niveau beskriver, hvilke data der er lagret i databasen og sammenhængene mellem dataene.
Det konceptuelle niveau indeholder hele databasens logiske struktur, som databaseadministratoren ser den.
Niveauet repræsenterer følgende:
• alle entiteter, deres attributter og deres sammenhænge
• dataenes begrænsninger
• semantisk information omkring dataene
• sikkerheds- og integritetsinformation
Det konceptuelle niveau understøtter de eksterne views, men må ikke indeholde detaljer, som er afhængige af lagringen.
4.1.2. Krav til fysisk databasedesign
Formålet er at oversætte det logiske design til en teknisk realisabel løsning.
Målet er at skabe et design hvormed data kan opbevares og bearbejdes (bruges) sikkert og hurtigt.
Det fysiske databasedesign omhandler endvidere valg af datatyper, relationer og normalisering af tabeller.
Det er på baggrund af det fysiske databasedesign at databasen oprettes i mySQL.
4.1.3. Krav til SQL Sætninger
De SQL Sætninger som skal afvikles i produktet, med det formål at behandle data i databasen skal overholde de standarder som benyttes i mySQL. Derfor skal den enkelte SQL Sætninger testes i mySQL admin modulet. Hvis der modtages en syntax error i mySQL admin modulet er SQL Sætningen ikke korrekt.
Der findes generelt to forskellige slags SQL-forespørgelser:
1. Forespørgelser der IKKE returnerer data (insert, update, delete osv).
2. Forespørgelser der returnerer data (fortrinsvist select).
4.2. ER – diagram
En entity-relationship data model giver os muligheden for at beskrive database designet vha. objekter og deres relationer. På denne måde kan vi skabe et overblik over, hvordan vi har tænkt os at databasen opbygges.
4.2.1. Entiteter, attributter, domæner og relationer
En entitet er et objekt i den virkelige verden. Det kan fx være en ting, en person eller et sted mm. En samling af lignende entiteter kaldes for et entity set. Ved lignende forstås at alle entiteter i et given entity set med samme attributter (kolonner).
Det er dog værd at bemærke, at entity set ikke behøver at være adskilt dvs. samme entitet godt kan fremkomme i to forskellige entity set.
En entitet er beskrevet ved hjælp af attributter. En attribut er en kolonne i databasen. Her kan vi f.eks. gemme navn og kundeID når en kunde oprettes i databasen.
For hvert attribut der er knyttet til et entity set, skal vi bestemme et domæne af mulige værdier f.eks. at kundens navn ikke må være længere en 30 karakterer.
For hvert entity set skal vi vælge nøgle. En nøgle er et minimalt sæt af attributter, hvis værdier identificerer en entitet i et sæt af entiteter. Der kan godt være flere ”kandidater” til nøglen, men én af dem udpeges til at være primary key. Vi kan nu forvente, at hvert sæt af entiteter indeholder et sæt af attributter, som identificerer en entitet i hele sættet.
4.2.2. ER – diagram
Vores ER diagram viser hvordan vores database er opbygget på nuværende tidspunkt. Hvis Forlaget ønsker det, kan systemet udvides med flere funktioner, hvilket vil betyde, at ER diagrammet tilsvarende udvides.
Se bilag 7
4.4. Transformation fra ER-model til relationel model
I transformation fra ER-model til relationel model beskrives transmission af SQL- forespørgelser til relationel algebra.
4.4.1. Relationel Algebra
Den relationelle algebra er en udvidelse af den matematiske algebra. Udover den matematiske algebra omfatter den relationelle algebra operationer på tabeller.
De vigtigste operationer:
(til nedenstående er R og S to tabeller)
Union foreningsmængde U
Intersection fællesmængde ∩
Selection sigma σbetingelse(R)
Projection pi πA(R)
Join
Cartesian product produkt x
Union : udskriver alle tubler i R og alle tubler i S.
Intersection : udskriver de tubler der findes i både R og S.
Selection : udskriver den / de tubler der opfylder betingelsen.
Projection : udskriver den / de attributter der opfylder betingelsen.
Join : udskriver den attribut der opfylder betingelsen for både R og S.
Cartesian product : udskriver alle tubler i R ”parret med” alle tubler i S.
Udover disse findes også operationer som differens (-), division (/) mm.
Relationel algebra gør det muligt at "regne" sig frem til information i den relationelle datamodel, det vil sige bruge ”gammel” data til at udregne ”ny” data.
Det der menes her er, at man indsamler data fra de seneste år, og derved udregner en model for udviklingen igennem årene. Når man har denne model, kan udviklingen for det kommende år estimeres. Selvfølgelig er dette resultat ikke 100 % sikkert, men derimod en fornemmelse af, hvordan året kommer til at forløbe. Hvis man kan regne sig frem til, at året bliver økonomisk trængende, kan man være på forkant og måske spare lidt, således at økonomien ikke falder helt fra hinanden.
For at kunne arbejde med tabellerne, skal de tabeller man vil hente data fra være ”union kompatible” dvs. have samme attributnavn (kolonnenavn).
SQL sætning:
"select * from Ordering inner join Customer on Ordering.CustomerID = Customer.CustomerID inner join PostalCode on Customer.PostalCode = PostalCode.PostalCode inner join Paid on Ordering.PaidID = Paid.PaidID where OrderID ="+OrderID
Ovenstående SQL sætning er taget fra PaymentOfBooks klassen i metoden FindInvoice(). For at gøre det mere overskueligt deles sætningen op i mindre bider og oversættes til relationel algebra.
select * from Ordering inner join Customer on Ordering.CustomerID = Customer.CustomerID inner join PostalCode on Customer.PostalCode = PostalCode.PostalCode inner join Paid on Ordering.PaidID = Paid.PaidID where OrderID = OrderID
(Customer p1 PostalCode),
p1: PostalCode=PostalCode
(Ordering p2 Customer),
p2: CustomerID=CustomerID
(Ordering p3 Paid),
p3: PaidID=PaidID
(σOrderID=OrderID (Ordering p1 (Customer p2 PostalCode)) ∩
(Ordering p3 Paid))
∏ U (σOrderID=OrderID (Ordering p1
(Customer p2 PostalCode)) ∩
(Ordering p3 Paid))
Oversat til relationel algebra vil den tidligere SQL-sætning komme til at se ud som følgende:
∏ U (σOrderID=OrderID (Ordering p1 (Customer p2 PostalCode)) ∩ (Ordering p3 Paid))
4.5. Normalisering
1. Normalform. En tabel er på første normalform, når der ikke er repeterende grupper i tabellen.
Designmetode: Find kolonner, der ikke er entydigt identificeret af primærnøglen (repeterende grupper). Udskil i en ny tabel.
2. Normalform. En tabel er på anden normalform, Når den er på 1NF og der ikke er felter som kan identificeres entydigt af en del af en sammensat primær nøgle.
Designmetode: Find kolonner, der kan identificeres entydigt ved kun en del af primærnøglen. Udskil i en ny tabel
3. Normalform. En tabel er på tredje normalform, når den er på 2NF og der ikke er felter i tabellen, som er entydigt afhængige af andre felter end primærnøglen.
Designmetode: Find kolonner, der er entydigt identificeret af andre kolonner end primærnøglen eller -nøglerne. Udskil i ny tabel.
I 3. normalform kan det være god skik i nogle tabeller at gå ned til en lavere normalform. Det kan være tilfældet i en kundetabel med postnummer og bynavn, hvor man med fordel kan undlade at lægge de to felter ud i en selvstændig tabel, hvis der kun kommer til at være 30 kunder i databasen. I et postnummer/by tabel skal alle postnumre og bynavne i Danmark være med. Det vil være bedre med 30 gentagelse af postnummer og bynavn end 4000 ubrugte.
4.5.1. Den normaliserede database
Den designede database er på 3 normalform idet ovenstående krav til 3. normalform er opfyldt.
4.5.2. Indeksering
Indeksering bruges til hurtigt at finde tubler i en specifik attribut. Hvis der ikke findes et indeks skal MySQL starte med den første attribut og derefter læse hele tabellen igennem for at finde de relevante tubler. Jo større en tabel jo længere tid tager det.
Indeksering er en metode til at opdele den enkelte tabel i flere dele. I databasen sker der indeksering af flere tabeller (f.eks. kan Customer tabellen indekseres efter postnummer.).
For at oprette et indeks af en tabel benyttes SQL sætningen:
CREATE INDEX PaymentStatusID
ON Customer (PaymentStatusID);
Denne sætning oprette et index i Customer tabellen på PaymentStatusID.
Den normaliserede database kan ses i Bilag 8.
4.6. Fysisk databasedesign
I det fysiske database design oprettes databasen, alle tabeller og egenskaberne for de enkelte dele defineres. Det er oprettelsen af selve databasen på harddisken med alt hvad der hører til.
4.6.1. Oprettelse af tabeller
En tabel oprettes på denne måde:
CREATE TABLE `Customer` (
`CustomerID` INT NOT NULL AUTO_INCREMENT,
`FirstName` VARCHAR(50) NOT NULL,
`LastName` VARCHAR(50) NOT NULL,
`Address` VARCHAR(100) NOT NULL,
`PostalCode` SMALLINT NOT NULL DEFAULT 0,
`Phone` VARCHAR(50) NOT NULL,
`Email` VARCHAR(100) NOT NULL,
`PaymentStatusID` INT NOT NULL DEFAULT 0,
`Company` VARCHAR(100),
INDEX `PaymentStatusCustomer` (`PaymentStatusID`),
INDEX `PaymentStatusID` (`PaymentStatusID`),
INDEX `PostalCode` (`PostalCode`),
INDEX `PostalCodeCustomer` (`PostalCode`),
PRIMARY KEY `PrimaryKey` (`CustomerID`)
);
Her er alle felter, datatyper, indekser og primær nøgle defineret for Customer tabellen.
4.6.2. Nedlæggelse af tabeller
Her bruges:
DROP TABLE IF EXISTS `Customer`;
4.6.3. SQL – forespørgelse til INSERT, UPDATE og DELETE
En INSERT sætning ser ud på denne måde:
INSERT INTO tabelnavn (Attributnavn1, Attributnavn2) VALUES(’Værdi1’, ’Værdi2’);
En UPDATE sætning ser ud på denne måde:
UPDATE tabelnavn SET Attributnavn1 = Værdi1, Attributnavn2 = Værdi2 WHERE Attributnavn3 = Værdi3;
En DELETE sætning ser ud på denne måde:
DELETE FROM tabelnavn WHERE Attributnavn1 = Værdi1;
4.6.4. SQL - forespørgelser til rapport udtræk
For at vise alt indhold på lageret og hvem som er forhandler af den enkelte vare:
Select * from Stock inner join Supplier on Stock.SupplierID = Supplier.SupplierID inner join PostalCode on PostalCode.PostalCode = Supplier.PostalCode;
For at hvor meget firmaet har modtaget i samlet indbetalinger:
Select Amount from Ordering where PaidID = 2
Derefter lægges de enkelte Amount værdier sammen og til sidst har man den endelige omsætning.
For at se salgsstatistik for hver enkelt bog benyttes:
Select * from Stock inner join OrderInfo on OrderInfo.ProductID = Stock.ProductID
Denne sætning henter informationer ud om hvilke varer som er blevet bestilt og i hvor stort antal og prisen for hver enkelte vare.
4.7. Sikkerhed og transaktioner
Ved brug af databaser, kan flere brugere have adgang til den same database på samme tid. Det vil forøge risikoen for tab af data i forbindelse med fejl i software og hardware. Behovet for at kunne varetage en pålidelig database er blevet større. For at beskytte databasen bruges transaktionsbegrebet.
En transaktion er en handling der udføres af en bruger eller et program, som medfører en ændring af data i en database.
• En transaktion skal altid bringe en database fra konsistent tilstand til en anden
• Vi tillader dog at databasen ikke er konsistent under selve transaktionen.
Følgende kan ske ved en transaktion:
• Hvis transaktionen gennemføres korrekt, er den ’committed’.
• Hvis transaktionen ikke gennemføres korrekt, er den ’aborted’.
• Hvis en transaktion bliver ’aborted’ foretages der en ’roll-back’ eller ’undone’.
• En transaktion der er blevet ’committed’, kan der ikke køres en ’roll-back’ på.
• Fortrydes en ’committed’ transaktion, foretages en kompenserende transaktion der bringer databasen tilbage til dens oprindelige form, før den forkerte transaktion blev foretaget.
• En transaktion der er kørt ’roll-back’ på, kan køres igen senere. Afhængig af årsagen til ’roll-backen’, kan den måske gennemføres denne gang.
Alle transaktioner skal være i besiddelse af en række egenskaber. De fire vigtigste, defineret som ACID, kan ses herunder:
• Atomic: Enten udføres transaktionen ellers gør den ikke. Halvt udførte transaktioner kan ikke forekomme.
• Consistency: En transaktion skal bringe databasen fra en konsistent tilstand til en anden.
• Isolation: Transaktioner udføres uafhængigt af hinanden. En ukomplet transaktion, der bliver kørt roll-back på, må altså ikke påvirke en anden transaktion.
• Durability: Data der er committed, bliver skrevet til databasen og må herefter ikke kunne blive påvirket af andre transaktioner.
4.8. Teori om DBMS
DBMS’en er det software der arbejder sammen med brugerens applikationer og database.
Den overordnet definition på DBMS (Database Management Systems) er et software system der bruges til at definere, oprette og vedligeholde store mængder data i en database. Der tilbydes kontrolleret adgang til databasen.
DBMS’en komponenter:
• Hardware: PC og Client-server
• Software: jBuilder 9 og jCreator (Java programerings-sprog)
• Database: Oprettet i MySQL. Strukturen kaldes dets schema, som består af en række tabeller. Tabellerne indeholder en række attributter.
• Procedure: Instruktioner eller regler til at fastsætte et design, og til brug af databasen. (f.eks. log-on)
• Mennesker: Dem der arbejder med databasen
Fordele og ulemper ved brug af DBMS:
Fordel Forklaring
Kontrol over data redundans Filsystemet spilder plads, ved at gemme den samme information i mere end én fil.
Redundans afskaffes IKKE helt i databasesystemet, men begrænses og kontrolleres
Eks. ID/Nøgler og replikerede data til performanceforbedringer
Data konsistens Forbedret konsistens i databasedata, når samme dataelement læses, redigeres og opdateres.
Mange DBMS´s sikrer desværre i dag IKKE fuld konsistens
Flere informationer kan uddrages fra samme datamængde Ved samkøring af flere data, kan ny sammenhænge udledes
Eks. Det offentliges samkøring af allerede eksisterende data
Deling af data (transaktionsstyring) Almindelige filer “ejes” som regel af enkeltpersoner eller afdelinger.
databaseinformationer ”tilhører” hele organisationen
Ny applikationer kan udvikles på eksisterende data.
Forbedret dataintegritet Da der er taget hånd om, hvorledes valide data ”ser” ud, sikres dataelementernes konsistens og integritet
Forbedret sikkerhed Databasesikkerhed kan af den enkelte DBA (Data Base Administrator) fastlægges så de brugere der har behov for en bestemt delmængde af data, kun får tilgang til dem.
Anvendelse af standarder DBA kan gennemtvinge fastlagte standarder af organisatorisk, national eller international karakter. Eks.  dansk registerlovgivning
Ringe investering ved bedre udnyttelse Hvis flere forskellige applikationer placeres ovenpå den eksisterende datamængde, udnyttes ressourcerne bedre, end hvis data skulle reetableres, f.eks. ved udvidelse i organisationen m.m.
Balancering af konflikt krav Forskellige brugere har forskellige krav til data, eller præsentationen af data.
Disse kan nemt afbalanceres så forskellige brugere har forskellig adgang til data, forskellige VIEWS, etc.
Bedre tilgængelighed og svarudnyttelse Ved. F.eks. brug af SQL (Structured Query Language) kan differentieret datatilgang foregå fra stort set hvilken location man ønsker
Forhøjet produktivitet Flere dele som en programmør, i et traditionelt filbaseret system, ville have brug for er indarbejdet i bl.a. SQL, så dette tillader ham at bruge mindre tid på low-level programmeringsdelen.
Forbedret vedligeholdelse vha. data-independence Ved ændringer i modellogikken er applikationer i DBMS IKKE så afhængige af andre dele, som i et traditionelt fil-baseret system
Forøgelse af ”concurrency” Vha. at læse/skrive lock problematikken
Forbedrede backup og recovery muligheder DBMS tilbyder backup faciliteter indbygget i systemet, der løbende laver opdateringer af data.
Figur 9: Fordele ved Database Management Systems (DBMS), taget fra
http://www.imada.sdu.dk/~wiggers/dm26/_Toc511627870Ulemper Forklaring
Kompleksitet Med den indbyggede kompleksitet er DBMS´en et stykke avanceret software
Størrelse af software Med den indbyggede kompleksitet er DBMS´en et stort stykke software
Pris på DBMS´s Forholdsvis dyr i anskaffelse, samt vedligehold og opdatering
Ekstra hardwareudgifter Den mængde data der skal behandles/opbevares kan kræve ekstra investeringer i hardware
Udgifter til konverteringer Udgifter til konvertering af eksisterende data, applikationer samt uddannelse af personale, kan antage en anseelig størrelse
Performance Da DBMS er skrevet som en mere generel softwareudvikling, kan performance være dårligere end kendte fil-baserede systemer.
Større effekt ved eventuelle fejl Den primært centraliserede opbygning af databasestrukturerne gør dem mere sårbare overfor fejl.
Figur 10: Ulemper ved Database Management Systems (DBMS), taget fra
http://www.imada.sdu.dk/~wiggers/dm26/_Toc5116278704.9. Database konklusion
Der er sket mange ændringer i databasen, siden projektets start. Det første databaseudkast blev lavet tidligt i projektforløbet. Det skete under en brainstorming, hvor gruppen snakkede om hvilke oplysninger vi kunne tænke os at have med, samt ud fra JA forlags ønsker. Grundet tid og ændringer i struktur og implementering har databasen fulgt produktets udvikling gennem hele forløbet. I starten af tre ugers perioden blev hele databasen redesignet. Grunden til dette var optimering af indeksering samt fejl i det oprindelige design. Siden da er der blevet slettet en tabel og omdøbt et felt. Som det kan ses i afsnittet om fremtidige udviklingsmuligheder vil der med mere design og implementering blive fyldt noget mere på databasen. Her kan yderligere nævnes eventuelle udvidelser til omfatning af flere lande.
Derudover er der et enkelt lille problem med databasen og det drejer sig om Orderinfo tabellen, hvor OrderID og ProductID fungerer som fælles primær nøgle. Der burde i stedet være et Auto_Increment felt som var primær nøgle. Problemet består i at hvis en kunde bestiller den samme vare 2 gange på samme OrderID, så giver det en fejl fordi produktet forsøger at gentage et OrderID og ProductID som primær nøgle. Den samme sekvens af OrderID og ProductID (f.eks. OrderID = 1 og ProductID = 2) må ikke gentages da sekvensen så ikke længere er unik.
Det er primært Nicolai som har stået for opbygning og ændringer i databasen, da han har størst erfaring med at udvikle databaser.
