1. Relationen mellan originaldokumentet och enheten
Det kan vara en-till-en, en-till-många och många-till-många-relationer. Generellt är de en-till-en-relationer: det vill säga ett par originaldokument
bör och endast motsvara en entitet. I speciella fall kan de vara en-till-många- eller många-till-en-relationer, dvs. ett originaldokument motsvarar flera verkligheter
kroppsdelen, eller flera originaldokument som motsvarar en enhet. Entiteten här kan förstås som en grundläggande tabell. Efter att ha klargjort denna korrespondens, designa för oss
Ingångsgränssnittet är mycket användbart.
〖Exempel 1〗: Informationen om ett medarbetar-CV motsvarar tre grundläggande tabeller i personalinformationssystemet: personalens grundläggande informationstabell och samhället
Relationstabell, arbets-CV-formulär. Detta är ett typiskt exempel på "ett originaldokument motsvarar flera enheter".
2. Primär- och främmande nycklar
Generellt kan en enhet varken ha en primär eller främmande nyckel. I E-R-diagrammet kan entiteterna i bladdelen definiera primärnyckeln,
Det är också möjligt att inte definiera en primärnyckel (eftersom den inte har några barn), men den måste ha en främmande nyckel (eftersom den har en fader).
Designen av primär- och främmande nycklar intar en viktig plats i utformningen av globala databaser. När designen av den globala databasen är klar finns en
Amerikanska experter på databasdesign sa: "Nycklar, nycklar överallt, inget annat än nycklar", detta är hans erfarenhet av databasdesign
Det speglar också hans mycket abstrakta idéer om kärnan i informationssystem (datamodeller). Eftersom: primärnyckeln är en mycket abstrakt entitet, och primärnyckeln är associerad med
Ett par främmande nycklar som representerar en koppling mellan entiteter.
3. Grundbordets natur
Grundtabellen skiljer sig från mellanliggande tabellen och den temporära tabellen eftersom den har följande fyra egenskaper:
(1) Atomicitet. Fälten i bastabellen är inte längre dekomponerbara.
(2) Primitivitet. Posterna i bastabellen är poster av den ursprungliga datan (den underliggande datan).
(3) Deduktiv. All utdata kan härledas från data i bastabellen och kodtabellen.
(4) Stabilitet. Strukturen i den grundläggande tabellen är relativt stabil, och posterna i tabellen bör bevaras under lång tid.
Efter att ha förstått grundläggande tabellers natur kan man vid databasdesign särskilja grundläggande tabeller från mellanliggande tabeller och temporära tabeller.
4. Paradigmstandarder
Relationen mellan grundtabellen och dess fält bör uppfylla det tredje paradigmet så mycket som möjligt. Databasdesigner som uppfyller det tredje paradigmet är dock ofta inte det
Den bästa designen. För att förbättra databasernas operativa effektivitet är det ofta nödvändigt att sänka paradigmstandarden: öka redundansen på ett lämpligt sätt för att uppnå utrymme för tid
Syftet med.
Exempel 2: Det finns en grundläggande tabell för lagring av varor, som visas i Tabell 1. Förekomsten av fältet "Belopp" indikerar att tabellen inte är utformad för att vara uppfylld
Det tredje paradigmet är tillräckligt, eftersom "mängd" kan erhållas genom att multiplicera "enhetspris" med "kvantitet", vilket indikerar att "mängd" är ett redundant fält. Öka dock
Det redundanta fältet "mängd" kan förbättra hastigheten på frågestatistik, vilket är praktiken att byta ut utrymme mot tid.
I Rose 2002 finns det två typer av föreskrivna kolumner: datakolumner och beräknade kolumner. En kolumn som "amount" kallas en "beräkningskolumn", och
Kolumner som "Enhetspris" och "Mängd" kallas "datakolumner".
Tabell 1 Tabellstruktur för råvarutabellen
Produktnamn, produktmodell, enhetspris, kvantitet, belopp
TV 29 tum 2 500 40 100 000
5. Förstå de tre paradigmen på ett enkelt sätt
Att förstå de tre paradigmen på lekmannaspråk är till stor nytta för databasdesign. I databasdesign, för att bättre tillämpa de tre paradigmen, är det bara
Tre paradigm måste förstås på lekmannaspråk:
Det första paradigmet: 1NF är en atomär begränsning på attribut, som kräver att attribut är atomära och inte längre kan dekomponeras;
Det andra paradigmet: 2NF är unikhetsbegränsningen på poster, vilket kräver att poster har en unik identifiering, det vill säga enhetens unikhet;
Paradigm 3: 3NF är en begränsning på fältredundans, det vill säga att inget fält kan härledas från andra fält, det kräver att fältet inte är redundant
。
Ingen redundant databasdesign kan göra det. Dock är en databas utan redundans inte nödvändigtvis den bästa databasen, ibland för att förbättra turen
För att uppnå effektivitet är det nödvändigt att sänka paradigmstandarden och behålla redundant data på ett lämpligt sätt. Det specifika tillvägagångssättet är att följa det tredje paradigmet vid design av konceptuella datamodeller
, arbetet med att minska paradigmstandarden beaktas vid utformningen av den fysiska datamodellen. Att sänka paradigmet innebär att lägga till fält som tillåter redundans.
6. Var bra på att identifiera och korrekt hantera många-till-många-relationer
Om det finns en många-till-många-relation mellan två enheter bör relationen elimineras. Sättet att eliminera det är att lägga till en tredje real mellan de två
kropp. På så sätt har det som brukade vara en många-till-många-relation nu blivit två en-till-många-relationer. Attributen för de ursprungliga två enheterna bör fördelas rimligt
Gå till de tre entiteterna. Den tredje entiteten här är i huvudsak en mer komplex relation, vilket motsvarar en grundläggande tabell. Generellt sett gäller siffror
Biblioteksdesignverktyget kan inte känna igen många-till-många-relationer, men det kan hantera många-till-många-relationer.
Exempel 3: I "Library Information System" är "book" en entitet, och "reader" är också en entitet. Dessa två enheter är samma
Relationen mellan böcker är typisk mängda-till-många-relation: en bok kan lånas av flera läsare vid olika tillfällen, och en läsare kan låna fler
Den här boken. För detta ändamål bör en tredje enhet läggas till mellan de två, kallad "lån och återlämnande böcker", och dess egenskaper är: lånetid och lån
Den har också en logotyp (0 betyder att låna en bok, 1 betyder att lämna tillbaka en bok), dessutom bör den också ha två främmande nycklar (primärnyckeln "bok" och primärnyckeln "läsare"), så att
Det kopplar till "böcker" och "läsare".
7. Värdemetoden för primärnyckeln PK
PK är ett inter-tabellsanslutningsverktyg för programmerare, som kan vara en talsträng utan fysisk betydelse, och som automatiskt läggs till av programmet till 1. Ja
är ett fysiskt meningsfullt fältnamn eller en kombination av fältnamn. Men det förra är bättre än det senare. När PK är en kombination av fältnamn, föreslår du ett fältnummer
Räkna inte för mycket, eftersom indexet inte bara tar upp mycket plats utan också saktar ner.
8. Få dataredundans rätt
Upprepningen av primär- och främmande nycklar i flera tabeller är inte ett begrepp om dataredundans, och många är inte medvetna om det
。 Upprepningen av icke-nyckelfält är dataredundans! Och det är en låg nivå av redundans, det vill säga repetitiv redundans. Avancerad redundans är inte fältbaserad
Upprepade gånger, men derivat av fält.
Exempel 4: De tre fälten "enhetspris, kvantitet och mängd" i produkten, "mängd" härleds från "styckpris" multiplicerat med "kvantitet"
Det är redundans, och det är en slags avancerad redundans. Syftet med redundans är att öka bearbetningshastigheten. Endast låg nivå av redundans ökar antalet
inkonsekvens i data, eftersom samma data kan matas in flera gånger från olika tider, platser och roller. Därför förespråkar vi avancerad redundans (pie)
redundans av naturen), och motsätter sig lågnivåredundans (repetitiv redundans).
9. Det finns inget standardsvar för E-R-diagram
Det finns inget standardsvar på E-R-diagrammet för ett informationssystem, eftersom dess design och ritningsmetod inte är unika, så länge det täcker den affärsmässiga verksamhet som systemet kräver
Omfattningen och det funktionella innehållet är genomförbart. Istället är det nödvändigt att modifiera E-R-diagrammet. Även om det inte finns ett enda standardsvar betyder det inte att det kan vara godtyckligt
Design. Kriterierna för ett bra E-R-diagram är: tydlig struktur, koncis association, måttligt antal enheter, rimlig attributallokering och ingen lågnivå-redundans.
10. Visningstekniker är användbara vid databasdesign
Till skillnad från grundläggande tabeller, kodtabeller och mellanliggande tabeller är vyer virtuella tabeller som är beroende av de verkliga tabellerna i datakällan för att existera. Vyer är för programmerare
Ett fönster som använder databasen är en form av bastabelldatasyntes, en metod för databehandling och en slags användardatakonfidentialitet
betyder. För att utföra komplex bearbetning, öka beräkningshastigheten och spara lagringsutrymme bör definitionsdjupet i vyn generellt inte överstiga tre lager. Typ tre våningar
Om vyn fortfarande inte räcker till bör du definiera en tillfällig tabell på vyn och sedan definiera en vy på den temporära tabellen. På detta sätt definieras vyns djup upprepade gånger
Inga begränsningar.
För vissa informationssystem relaterade till nationella politiska, ekonomiska, teknologiska, militära och säkerhetsintressen är åsikternas roll ännu viktigare. Dessa
Efter att den fysiska designen av systemets grundtabell är färdigställd, etableras det första lagret av vyer omedelbart på grundtabellen, och antalet och strukturen för denna lagervy är desamma som i grundtabellen
Antalet och strukturen är exakt desamma. Och det är föreskrivet att alla programmerare endast får arbeta med vyn. Endast databasadministratören, med
"Säkerhetsnyckeln" som hålls av flera personer kan användas direkt på grundbordet. Läsare uppmanas att fundera: varför är det så?
11. Mellanliggande tabeller, satser och temporära tabeller
En mellanliggande tabell är en tabell som lagrar statistik, den är designad för datalagring, utdatarapporter eller frågeresultat, och ibland har den ingen primärnyckel med
främmande nycklar (förutom datalager). Temporära tabeller är utformade av programmerare för att lagra temporära poster för personligt bruk. Bas- och mellantabellerna underhålls av DBA
Tillfälliga tabeller underhålls automatiskt av programmeraren själv.
12. Integritetsbegränsningar manifesteras i tre aspekter
Domänintegritet: Använd Check för att implementera begränsningar, och i databasdesignverktyget finns ett Ch när värdeintervallet för fältet definieras
Eck-knappen, genom vilken värdestaden för fältet definieras.
Referensintegritet: Implementerad med PK-, FK- och tabellnivå-triggers.
Användardefinierad integritet: Det är vissa affärsregler som implementeras med lagrade procedurer och triggers.
13. Metoden för att förhindra patching av databasdesign är principen "tre mindre"
(1) Ju färre tabeller i en databas, desto bättre. Endast om antalet tabeller minskas kan det sägas att E-R-diagrammet för systemet är litet och fint, och det tas bort
De dubblett- och redundanta enheterna utgör en hög grad av abstraktion av den objektiva världen, och systematisk dataintegration genomförs för att förhindra patchdesign;
(2) Ju färre fält i en tabell som kombinerar primärnycklar, desto bättre. På grund av primärnyckelns roll är den ena att bygga primärnyckelindexet, och den andra fungerar som en deltabell
främmande nycklar, så antalet fält i kombinationen av primärnycklar minskas, vilket inte bara sparar körtid utan även indexlagringsutrymme;
(3) Ju färre fält i en tabell, desto bättre. Endast ett litet antal fält indikerar att det inte finns någon dataduplicering i systemet
Det finns lite dataredundans, och viktigare är att läsare uppmanas att lära sig att "ändra rader", vilket förhindrar att fält dras in i huvudtabellen i undertabellen
, vilket lämnar många fria fält i huvudtabellen. Den så kallade "kolumnbytesraden" är att ta ut en del av innehållet i huvudtabellen och bygga en separat
Undertabell. Denna metod är väldigt enkel, vissa vänjer sig helt enkelt inte, tar inte till sig den och implementerar den inte.
Den praktiska principen för databasdesign är att hitta rätt balans mellan dataredundans och bearbetningshastighet. "Tre mindre" är en helhetsöversikt
Tanke, omfattande synsätt, kan inte isolera en viss princip. Principen är relativ, inte absolut. Principen om "tre till till" är definitivt fel. Försök
Tänk: Om samma funktion i systemet täcks är E-R-diagrammet med 100 enheter (totalt 1 000 attribut) definitivt bättre än E-R-diagrammet med 200 enheter (totalt 2 000 attribut)
E-R-diagrammet är mycket bättre.
Att förespråka principen om "tre mindre" är att låta läsare lära sig använda databasdesignteknik för systematisk dataintegration. Stegen för dataintegration ska följa:
Filsystemet är integrerat i en applikationsdatabas, applikationsdatabasen integreras i en ämnesdatabas och ämnesdatabasen integreras i en global omfattande databas.
Ju högre grad av integration, desto starkare är datadelningen och desto mindre informationsöar finns
Antalet primärnycklar och antalet attribut kommer att vara färre.
Syftet med att förespråka principen om "tre mindre" är att förhindra att läsare använder patchteknik för att ständigt lägga till, radera och modifiera databasen, för att skapa företagsdata
Biblioteket har blivit en "sophaug" av godtyckligt designade databastabeller, eller en "röra" av databastabeller, och orsakar slutligen de grundläggande tabellerna och generationerna i databasen
Kodtabeller, mellanliggande tabeller och temporära tabeller är röriga och oräkneliga, vilket leder till att informationssystemen i företag och institutioner inte kan underhållas och paralysera dem.
"Tre tillägg"-principen kan göras av vem som helst, vilket är felslutet i "patchningsmetoden" för att designa databaser. Principen om "tre mindre"
Det är en princip om mindre men fint, vilket kräver höga färdigheter i databasdesign och konst, vilket inte alla kan göra, eftersom denna princip elimineras
Den teoretiska grunden för att designa databasen med hjälp av "patchningsmetoden".
14. Sätt att förbättra effektiviteten i databasens drift
Under de givna systemhårdvaru- och systemmjukvaruförhållandena är metoderna för att förbättra databassystemets driftseffektivitet:
(1) I databasens fysiska design, minska paradigmet, öka redundansen, använda färre triggers och använda fler lagrade procedurer.
(2) När beräkningen är mycket komplex och antalet poster mycket stort (till exempel 10 miljoner), måste den komplexa beräkningen först ske utanför databasen
Efter att filsystemmetoden har beräknats och bearbetats i C++-språket läggs den slutligen till i tabellen. Detta är erfarenheten av design av telekomfaktureringssystem.
(3) Om en tabell visar sig ha för många poster, såsom mer än 10 miljoner, bör tabellen delas horisontellt. Praktiken med horisontell segmentering är:
Dela tabellens post horisontellt i två tabeller baserat på ett visst värde av tabellens primära nyckel PK. Om en tabell visar sig ha för många fält, såsom övergående
Åttio är bordet vertikalt uppdelat och det ursprungliga bordet delas i två bord.
(4) Systemoptimering av databashanteringssystemet DBMS, det vill säga optimering av olika systemparametrar, såsom antalet buffertar.
(5) När du använder dataorienterat SQL-språk för programmering, försök att använda optimeringsalgoritmer.
Kort sagt, för att förbättra databasens driftseffektivitet är det nödvändigt att optimera databassystemet, databasdesignen och programimplementeringen
, dessa tre nivåer arbetar hårt samtidigt.
De ovanstående fjorton färdigheterna sammanfattas gradvis av många personer i ett stort antal databasanalys- och designmetoder. För dessa upplevelser
Läsare ska inte vara stela eller mekaniska, utan bör smälta och förstå, söka sanning i fakta och behärska flexibelt. Och gradvis gör det: skicka in ansökan
utställning, tillämpning i utveckling.
|
Publicerad på 2015-04-09 21:00:54
|
|
|
