Innledning

relasjonsdatabase ble foreslått av Edgar Codd (av IBM Research) rundt 1969. Det har siden blitt den dominerende database modell for kommersielle anvendelser (i sammenligning med andre database modeller som hierarkisk, nettverk og objekt modeller). I dag er det mange kommersielle Relational Database Management System (RDBMS), slik som Oracle, IBM DB2 og Microsoft SQL Server., Det er også mange gratis og » open-source RDBMS, som MySQL, mSQL (mini-SQL) og den innebygde JavaDB (Apache Derby).

En relasjonsdatabase organiserer data i tabeller (eller relasjoner). En tabell består av rader og kolonner. En rad er også kalt en post (eller tuple). En kolonne kalles også et felt (eller attributt). En database tabell ligner på et regneark. Imidlertid forhold som kan bli opprettet blant bordene aktivere en relasjonsdatabase for effektivt å lagre enorme mengder data, og effektivt hente utvalgte data.,

Et språk som kalles SQL (Structured Query Language) ble utviklet for å fungere med relasjonsdatabaser.

Database Design Mål

En godt utformet database skal:

  • Eliminere Data Redundans: samme stykke data skal ikke lagres i mer enn ett sted. Dette er fordi duplisere data ikke bare avfall lagringsplasser, men også lett føre til uoverensstemmelser.
  • Sikre Data Integritet og Nøyaktighet:
  • mer

relasjonsdatabase Design Process

Database design er mer kunst enn vitenskap, som du må ta mange avgjørelser., Databaser er vanligvis tilpasset et bestemt program. Ingen to tilpassede programmer er helt like, og dermed, ingen database er like. Retningslinjer (vanligvis i form av hva som ikke skal gjøre i stedet for hva du skal gjøre) er gitt i å gjøre disse design-vedtak, men de valgene som til slutt hvile på deg – designer.

Trinn 1: Definere Formålet med Databasen (behovsanalyse)

Samle de krav og definere mål av databasen, f.eks. …

Utarbeidelse ut prøven innspill skjemaer, spørringer og rapporter, hjelper ofte.,

Trinn 2: Samle inn Data, Organisere i tabeller og Angi den Primære Tastene

Når du har bestemt på formålet med databasen, samle inn data som er nødvendig for å bli lagret i databasen. Dele dataene inn i motivet-basert bord.

Velg en kolonne (eller noen kolonner) som den såkalte primærnøkkel, som unikt identifiserer hver av radene.

primærnøkkel

I relasjonell modell, en tabell kan ikke inneholde dupliserte rader, fordi det ville skape uklarheter i henting., For å sikre entydighet, hvert bord skal ha en kolonne (eller et sett med kolonner), kalles primær-tasten, som unikt identifiserer alle poster i tabellen. For eksempel, et unikt nummer customerID kan brukes som primærnøkkel for Customers bordet; productCode for Products bordet; isbn for Books tabell. En primærnøkkel er kalt en enkel tasten hvis det er en enkelt kolonne, det kalles en kompositt-tasten hvis det er laget av flere kolonner.,

de Fleste RDBMSs bygge en indeks på primær-tasten for å legge til rette raske søk og gjenfinning.

Den primære tasten brukes også til å henvise til andre tabeller (for å bli utdypet senere).

Du må bestemme deg for hvilke kolonnen(e) som skal brukes for primærnøkkelen. Vedtaket kan ikke være rett frem, men den primære nøkkelen skal ha disse egenskapene:

  • verdiene av primærnøkkel skal være unik (dvs., ingen dupliserte verdi)., For eksempel, customerName kan ikke være egnet til å brukes som primærnøkkel for Customers bordet, så det kan være to kunder med samme navn.
  • Den primære nøkkelen skal alltid ha en verdi. Med andre ord, det skal ikke inneholde NULL.

bør du Vurdere følgende i velg den primære nøkkelen:

  • Den primære nøkkelen skal være enkel og kjent, for eksempel, employeeID for employees bordet og isbn for books tabell.,
  • verdien av primærnøkkelen bør ikke endres. Primærnøkkel brukes til å henvise til andre tabeller. Hvis du vil endre verdien, må du endre alle sine referanser, ellers referanser vil bli tapt. For eksempel, phoneNumber kan ikke være egnet til å brukes som primærnøkkel for tabellen. Customers, fordi det kan endre seg.
  • primærnøkkel ofte bruker heltall (eller nummeret) type. Men det kan også være andre typer, slik som tekster. Imidlertid, det er best å bruke numeriske kolonne som primærnøkkel for effektivitet.
  • primærnøkkel kan ta et vilkårlig antall., De fleste RDBMSs støtte såkalte auto-tilvekst (eller AutoNumber type) for integer primary key, hvor (gjeldende maksimale verdi + 1) er tilordnet til den nye posten. Dette vilkårlig antall faktum er-mindre, da det inneholder ingen faktiske opplysninger. I motsetning til faktiske opplysninger som telefonnummer, faktisk-mindre antall er ideelt for primærnøkkel, så det kan ikke endres.
  • primærnøkkel er vanligvis en enkelt kolonne (f.eks., customerID eller productCode). Men det kan også gi opp av flere kolonner. Du bør bruke så få kolonner som mulig.,

Let’s illustrate with an example: a table customers contains columns lastName, firstName, phoneNumber, address, city, state, zipCode. The candidates for primary key are name=(lastName, firstName), phoneNumber, Address1=(address, city, state), Address1=(address, zipCode). Name may not be unique. Phone number and address may change., Derfor er det bedre å lage et faktum-mindre auto-inkrement nummeret, sier customerID, som primærnøkkel.

Trinn 3: Opprette Relasjoner mellom Tabeller

En database som består av uavhengige og ikke-relaterte tabeller tjener liten hensikt (du kan vurdere å bruke et regneark i stedet). Kraften av relasjonsdatabase ligger i forhold som kan defineres mellom tabeller. Den mest viktig aspekt i utformingen av en relasjonsdatabase er å identifisere relasjoner mellom tabeller., Typene forholdet inkluderer:

  1. en-til-mange –
  2. mange-til-mange –
  3. en-til-en –
En-til-Mange –

I en «klasse vaktliste» database, en lærer kan undervise i null eller flere klasser, mens en klasse som ble undervist av ett (og bare ett) lærer. I en «selskapet» database, en manager administrerer null eller flere ansatte, mens en ansatt er administrert av én (og bare én) manager. I et «salg» – database, kan kunden kan plassere mange bestillinger, mens en ordre er plassert ved en bestemt kunde. Denne typen forhold er kjent som en-til-mange.,

En-til-mange-relasjon kan ikke være representert i en enkelt tabell. For eksempel, i en «klasse vaktliste» database, kan vi begynne med en tabell kalt Teachers, som lagrer informasjon om lærere (for eksempel name, office, phone og email). For å lagre klasser undervises av hver lærer, kunne vi lage kolonner class1, class2, class3, men står overfor et problem umiddelbart på hvor mange kolonner for å lage., På den annen side, hvis vi begynner med en tabell kalt Classes, som lagrer informasjon om en klasse (courseCode, dayOfWeek, timeStart og timeEnd); vi kan opprette flere kolonner for å lagre informasjon om (en) lærer (for eksempel name, office, phone og email). Men, siden en lærer som kan undervise i mange klasser, dens data ville bli duplisert i mange rader i tabellen Classes.,

for Å støtte en en-til-mange-relasjon, må vi design to tabeller: en tabell med Classes for å lagre informasjon om klasser med classID som primærnøkkel, og et bord Teachers for å lagre informasjon om lærere med teacherID som primærnøkkel. Vi kan da lage en-til-mange-relasjon ved å lagre primærnøkkel i tabellen Teacher (dvs.,, teacherID) («en»-utgangen eller den overordnede tabellen) i tabellen classes («mange»-end eller barnet tabell), som illustrert nedenfor.

kolonnen teacherID i barnet tabell Classes er kjent som en sekundærnøkkel. En sekundærnøkkel av et barn bordet er en primærnøkkel av en forelder tabell, brukes til å referere til den overordnede tabellen.

merk at for hver verdi i den overordnede tabellen, kan det være null, ett eller flere rader i barnet bordet., For hver verdi i barnet tabellen, er det én og bare én rad i den overordnede tabellen.

Mange-til-Mange –

I et «salg» – database, kan kundens bestilling kan inneholde ett eller flere produkter, og et produkt som kan vises i mange bestillinger. I en «bokhandel» database, en bok som er skrevet av en eller flere forfattere, mens en forfatter kan skrive null eller flere bøker. Denne typen forhold er kjent for så mange-til-mange.

La oss illustrere dette med et «salg» – database. Vi begynner med to tabeller: Products og Orders., Tabellen products inneholder informasjon om produktene (for eksempel name, description og quantityInStock) med productID som primær-tasten. Tabellen orders inneholder kundens ordre (customerID, dateOrdered, dateRequired og status). Igjen, vi kan ikke lagre det bestilt innenfor Orders bordet, så vi vet ikke hvor mange kolonner for å reservere elementer., Vi kan heller ikke lagre for informasjon i Products tabell.

for Å støtte mange-til-mange-relasjon, må vi opprette en tredje tabell (kjent som et knutepunkt i tabellen), sier OrderDetails (eller OrderLines), der hver rad representerer et element av en bestemt rekkefølge. For OrderDetails bordet, primærnøkkelen består av to kolonner: orderID og productID, som unikt identifiserer hver rad., Kolonnene orderID og productID i OrderDetails bordet er brukt for å referere til Orders og Products tabeller, derfor, de er også de utenlandske nøkler i OrderDetails tabell.

mange-til-mange-relasjon er, faktisk, gjennomført som to en-til-mange-relasjoner, med innføring av krysset bordet.

  1. En ordre har mange elementer i OrderDetails. En OrderDetails elementet tilhører en bestemt rekkefølge.,
  2. Et produkt kan vises i mange OrderDetails. Hver OrderDetails – element er angitt ett produkt.
En-til-En –

I et «salg» database, et produkt kan ha ekstra utfyllende informasjon som for eksempel image, moreDescription og comment. Å holde dem innenfor Products tabell resulterer i mange tomme områder (i disse postene uten disse ekstra data). Videre, disse store data som kan forringe ytelsen til databasen.,

i Stedet, kan vi skape en annen tabell (si ProductDetails, ProductLines eller ProductExtras) for å lagre den valgfrie data. Et kort vil bare bli opprettet for de som er produkter med ekstra data. De to tabellene, Products og ProductDetails, viser en én-til-én-forhold. Det vil si at for hver rad i den overordnede tabellen, det er på de fleste en rad (muligens null) i barnet bordet. Den samme kolonnen productID skal brukes som primærnøkkel for begge tabellene.,

Noen databaser begrense antall kolonner som kan opprettes i en tabell. Du kan bruke et én-til-én-forhold til å dele data i to tabeller. Én-til-én-forhold er også nyttig for lagring av visse sensitive data på en sikker bordet, mens de ikke-sensitive seg i hovedtabellen.

Kolonne Datatyper

Du må velge en passende datatypen for hver kolonne. Ofte datatyper inkluderer: heltall, floating-point-tall, string (eller tekst), dato/tid, binære, innsamling (for eksempel opplisting og set).,

Trinn 4: Avgrense & Normalisere Design

For eksempel,

  • for å legge til flere kolonner,
  • opprette en ny tabell for ekstra data ved hjelp av én-til-én-forhold,
  • split et stort bord i to mindre bord,
  • andre.
Normalisering

Bruk den såkalte normalisering regler for å kontrollere om din database er strukturelt riktig og optimal.

Første Normal Form (1NF): EN tabell er 1NF hvis hver celle inneholder en enkelt verdi, ikke en liste over verdier. Denne egenskaper er kjent som atomic., 1NF forbyr også å gjenta gruppe med kolonner som item1, item2,.., itemN. I stedet bør du opprette en ny tabell ved hjelp av en-til-mange-relasjon.

Andre Normale Form (2NF): EN tabell er 2NF, hvis det er 1NF og alle ikke-nøkkel-kolonnen er helt avhengig av primærnøkkelen. Videre, hvis primærnøkkelen består av flere kolonner, hver eneste ikke-tasten kolonnen skal avhenge av hele settet og er ikke en del av det.,

For eksempel, er den primære nøkkelen til OrderDetails tabell bestående av orderID og productID. Hvis unitPrice er avhengig bare på productID, det skal ikke bli holdt i OrderDetails bordet (men i Products tabell). På den annen side, hvis unitPrice er avhengig av produktet, så vel som bestemt rekkefølge, så det skal bli holdt i OrderDetails tabell.,

Tredje Normale Form (3NF): EN tabell er 3NF, hvis det er 2NF og ikke-tasten kolonner er uavhengige av hverandre. Med andre ord, ikke-tasten kolonner er avhengig av primærnøkkelen, bare på primærnøkkel og ikke noe annet. For eksempel, la oss anta at vi har en Products tabell med kolonner productID (primærnøkkel), name og unitPrice., Kolonnen discountRate skal ikke tilhører Products bordet dersom det er også avhengig unitPrice, som ikke er en del av primærnøkkelen.

Høyere Normal Form: 3NF har sine mangler, som fører til høyere Normal form, for eksempel Boyce/Codd Normal form, Fjerde Normal Form (4NF) og Femte Normal Form (5NF), som er utenfor omfanget av denne opplæringen.

Til tider, du kan velge å bryte noen av de normalisering regler for ytelse grunn (f.eks., opprette en kolonne som heter totalPrice i Orders tabell som kan være avledet fra orderDetails oppføringer), eller fordi den brukeren blir bedt om det. Sørg for at du fullt klar over det, utvikle programmering logikk for å håndtere det, og det er riktig dokument nr.

Integritet Regler

Du bør også gjelde integritet regler for å kontrollere integriteten av din design:

Enhet Integritet Regel: Den primære nøkkelen kan ikke inneholde NULL. Ellers, det kan ikke identifisere rad., For kompositt-tasten består av flere kolonner, ingen av kolonne kan inneholde NULL. De fleste av RDBMS kontrollere og håndheve denne regelen.

referanseintegritet Regel: Hvert foreign key verdien må være tilpasset en primærnøkkel verdien i tabellen refereres til (eller forelder tabell).

  • Du kan sette inn en rad med en sekundærnøkkel i barnet tabellen bare hvis verdien finnes i den overordnede tabellen.
  • Hvis verdien av de viktigste endringene i den overordnede tabellen (f.eks., raden oppdatert eller slettet), alle rader med dette foreign key i barnet tabellen(e) må håndteres deretter., Du kan enten (a) ikke tillate de endringer; (b) kaskade endringen (eller slette oppføringer) i barnet tabeller i henhold til; (c) set key-verdi i barnet bord til NULL.

de Fleste RDBMS kan bli satt til å utføre kontroller og sikre referanseintegritet, i den angitte måte.

forretningslogikk Integritet: Ved siden av de to ovennevnte generelle integritet regler, kan det være integritet (validering) knyttet til business logic, f.eks.,, zip-koden skal være 5-sifret innen visse områder, dato og klokkeslett for levering, skal falle i den arbeidstid; antall bestilt skal være lik eller mindre enn kvantitet på lager, etc. Disse kan utføres i validering regel (for bestemt kolonne) eller programmering logikk.

Kolonne Indeksering

Du kan opprette indeks på valgt kolonne(r) for å forenkle data søking og gjenfinning. En indeks er et strukturert fil som gir raskere tilgang til data for SELECT, men kan bremse ned INSERT, UPDATE, og DELETE., Uten en indeks struktur, til å behandle en SELECT spørring med en matchende kriteriet (f.eks., SELECT * FROM Customers WHERE name='Tan Ah Teck'), databasemotoren behov for å sammenligne alle postene i tabellen. En spesialisert indeks (f.eks., i BTREE struktur) kan nå ta opp uten å sammenligne alle poster. Imidlertid indeksen må bygges opp på nytt når en oppføring er endret, noe som resulterer i overhead forbundet med å bruke indekser.

Indeksen kan være definert på en enkelt kolonne, et sett med kolonner (kalt sammensatt indeks), eller en del av en kolonne (f.eks., først 10 tegn av en VARCHAR(100)) (kalles delvis index) . Du kan bygget mer enn en indeks i en tabell. For eksempel, hvis du ofte søker etter en kunde enten ved hjelp av customerName eller phoneNumber, kan du øke hastigheten på søket ved å bygge en indeks på kolonnen customerName samt phoneNumber. De fleste RDBMS indeksen bygger på den primære nøkkelen automatisk.

REFERANSER & RESSURSER

Nyeste versjonen testet: MySQL 5.5.15
– Sist endret: September 2010

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *