Ryska federationens regering

National Research University

Högskolan för ekonomi

PERM-gren

Institutionen för informationsteknologi i företag

Informationsteknologi i kontorsarbete

Utveckling av ett företagsinformationssystem med hjälp av Access 2007-databashanteringssystemet

Studiehandledningen

Perm 2011

Informationsteknologi i kontorsarbete. Utveckling av ett företagsinformationssystem med hjälp av databashanteringssystemet Access 2007. Lärarhjälp. NRU HSE PF, 2011, 40 s.

Sammansatt av: Vikentieva Olga Leonidovna, Lebedev Valery Viktorovich.

Lärarstödet sammanställs i enlighet med den statliga utbildningsstandarden, läroplanen och begreppet disciplin "Information Technologies in Economics". Manualen är avsedd för studenter och lärare vid Higher School of Economics PF och innehåller en serie praktiska övningar som avslöjar möjligheterna med modern informationsteknologi för att skapa system för lagring, hämtning och presentation av data.

Granskare: Docent vid Institutionen för informatik vid Perm Regional Institute of Pedagogical Information Technologies, kandidat för pedagogiska vetenskaper, motsvarande medlem av Academy of Informatization of Education V.O.

Lektion 1: Designa en relationsdatabas

I vanlig mening är en databas en fil eller en uppsättning filer med en viss organisation. När man arbetar med konventionella filbehandlingssystem uppstår emellertid ett antal problem, i synnerhet med redundansen och beroendet av de data som lagras i dem. Vid design av en databas löses dessa problem.

Användaren bör delta i databasdesignprocessen, eftersom bara han kan bestämma vilka data som är nödvändiga för arbete, ange länkarna som finns mellan dessa data och uppmärksamma finesserna i deras behandling.

Informationsbehovet för en enskild användare påverkar vanligtvis endast en del av de data som lagras i informationssystemet, och beskrivningen av dessa behov kanske inte sammanfaller med beskrivningarna av andra användares behov. Idén om vilken typ av information som krävs för arbete kommer att vara annorlunda för olika grupper av användare, specialister inom olika områden - det beror på de uppgifter de utför (en specialist inom HR-avdelningen och redovisningsanställda, en avdelningschef etc. behöver utföra sina funktioner i olika data). Dessa behov beskrivs på yttre nivå datavyer (vyer A, B och C i figur 1).

Därför kan det finnas många externa beskrivningar av data lagrade i databasen. De behöver sammanföras konceptuell representationbeskriver data på nivån för hela informationssystemet som helhet. Presentationen av dessa data internt bestäms av hur de lagras i externt minne.

Låt oss överväga ett exempel på en databas med ett informationssystem för ett företag som bedriver leverans av varor till stadsbutiker, och vi tar bara hänsyn till informationsbehovet för två anställda i företaget (i en förenklad form - annars skulle exemplet vara för klumpigt).

Figur 1. Bildande av datapresentation

En kundrelationsansvarig behöver informationen som visas i figur 2 för att utföra sina uppgifter.

För en anställd som arbetar med betalningsformulär krävs annan information om kunderna (figur 3).

Uppgifterna som används av enskilda specialister finns i företagets enhetliga informationssystem, i en gemensam databas för dem. Därför måste de externa representationerna för enskilda användare integreras i den konceptuella representationen, syftet med att beskriva data på den konceptuella nivån är att skapa en sådan formell representation av informationen att varje extern representation är en delmängd av den. I processen att integrera externa representationer elimineras oklarheter och motsägelser i informationsbehovet för enskilda användare. En konceptuell beskrivning som representerar hela databasen bör vara unik.

Bild 2. Data för den första anställden

Bild 3. Data för den andra anställda

I detta exempel bör den konceptuella vyn innehålla all information som krävs av alla anställda. Konflikter kan uppstå på grund av att anställda som använder allmän information kan tänka på den på olika sätt (till exempel: ett telefonnummer kan skrivas i olika format). Alla dessa motsägelser måste elimineras, uppgifterna och formen av deras presentation måste vara konsekvent.

Därefter bestäms den konceptuella beskrivningen av följande information

De data som beskrivs i det konceptuella diagrammet måste registreras i ett externt minne, på en OVC, avsedd för lagring av information i databasen. Intern databeskrivning beskriver hur data lagras i externt minne.

Reglerna för databeskrivning bestäms av den valda datamodell (i detta fall betraktas bara den relationella modellen - den vanligaste för närvarande).

Om vi \u200b\u200btar beskrivningen av kunddata för ett företag som levererar varor till stadsbutiker från ovanstående exempel, som visas i fig. 4, kan data som beskrivs i denna tabell inte representeras i den här formen i en relationsdatabas, eftersom inte alla värden är atomiska ( komponenterna i strängarna "Ägare" och "Adress" består av flera värden, dvs värdena på dessa attribut ersätts av andra relationer, dekrypteras av dem; i relationen som beskriver ägaren är fälten "Adress" och "Pass" inte heller atomära, därför byggs en hierarki förbindelser).

Vid utformning av en databas kan olika beslut fattas, men det finns grundläggande krav som måste beaktas i arbetet: en uppsättning relationer måste säkerställa minimikrav för informationspresentation; manipulation av data, justering av relationer bör inte leda till brott mot dataintegritet, tvetydighet och förlust av information; ombyggnaden av uppsättningen av relationer när du lägger till nya attribut till databasen borde vara minimal.

Bild 4. Översikt över data

Beskrivningen av verkliga föremål och förhållandena mellan dem är till stor del subjektiv, men det finns vissa allmänna regler, särskilt normaliseringsregler... Normalisering skyddar dataintegritet genom att eliminera duplicering av data. Som ett resultat kan presentationen av data om ett objekt delas upp i flera mindre relaterade tabeller (förlustfri nedbrytning). De begränsningar som måste uppfyllas vid utformningen av en relationsdatabas är många. Överensstämmelse med begränsningar för att definiera specifika relationer i databasen är implementeringsrelaterat normala former... Normala former numreras i följd, med början från den första. Ju större antalet normalformulär som databasen uppfyller, desto fler begränsningar för data lagrade i databasen måste följas. Det är möjligt att införa en ytterligare uppsättning begränsningar för de begränsningar som är typiska för relationella DBMS: er, vilket kommer att leda till en ökning av antalet normala former.

I en dåligt utformad databas kan all information lagras i en tabell. För exemplet som beskrivs ovan kan en sådan tabell innehålla följande kolumner:

Street- och Home-adresskomponenterna har bytt namn till att uppfylla kravet på att kolumnnamn måste vara unika (namnreglerna beror på det specifika DBMS).

Vilka är nackdelarna med en sådan idé?

Första normala formen kräver att det vid varje skärningspunkt mellan en rad och en kolumn finns ett enda värde som måste vara odelbart (krav på atomicitet). Dessutom bör det inte finnas några duplicerade rader och datagrupper i en relationstabell.

Kravet på atomicitet uppfylls - de sammansatta kolumnerna "Adress" och "Ägare" (och för ägaren "Adress" och "Pass") är indelade i komponenter som ingår i den allmänna tabellen. Men en butik kan ha flera ägare, och en person kan äga flera butiker. Detta leder till att bordet måste inkludera alla rader som representerar "kombinationer" av butiker och deras ägare, dvs. datagrupper upprepas i olika rader (data om butiken upprepas flera gånger - för varje ägare, och ägardata upprepas för varje butik). Denna datapresentation leder till enorm redundans, till att minnet på OVC kommer att användas ineffektivt. Dessutom kan dubblering av information leda till problem i behandlingen: för att göra ändringar i informationen om butiken (till exempel om den ändrar bankkontot) måste du ändra denna information i flera poster motsvarande olika ägare.

Vid bestämning av vilka tabeller som ska inkluderas i databasen och vilken information som ska lagras i dem bör följande regel beaktas: varje tabell beskriver ett objekt, existerande oberoende, med egna egenskaper. Att bygga en databas bör börja med att skapa en representation av varje objekt i form av rader som innehåller dess attribut i motsvarande tabell; definition av modeller för sammankoppling av objekt. I det här exemplet bör databasen faktiskt lagra information om objekt av två typer: om butiker och om deras ägare. Denna information ska placeras i två olika tabeller (butiker och ägare) med följande kolumner:

"Affärerna"

"ägare"

Varje rad i tabellen Butiker beskriver ett exempel på motsvarande objekt (en butik). Varje rad i tabellen "Ägare" innehåller information om en butiksägare.

När du arbetar med information lagrad i en databas måste DBMS kunna skilja rader från varandra. Ett attribut eller uppsättning attribut som identifierar en rad unikt är dess primära nyckel.

Vad kan väljas som den primära nyckeln för tabellerna som beskrivs ovan?

Nyckel en relation är en sådan uppsättning attribut att varje kombination av deras värden endast förekommer i en rad i relationen och ingen delmängd av dessa attribut har den här egenskapen. Således identifierar nyckeln unikt raden, låter dig välja den från hela uppsättningen rader i relationen.

Låt oss definiera en nyckel för tabellen Stores.

Om du väljer attributet "Butiksnamn" som nyckel, kommer det att uppfylla det angivna kravet? Nej, om det i samma stad kan finnas flera butiker med samma namn i olika delar av staden. För att säkerställa otvetydighet bör butiksnamnet kompletteras med dess adress (med butikens namn och dess adress kan du otvetydigt välja önskad rad i tabellen), då kommer relationsknappen att vara sammansatt.

En enkel nyckel som identifierar önskad butik kan vara ett bankkontonummer (om varje butik har ett enda bankkontonummer och varje aktuellt konto tillhör en butik). Nyckeln kan också vara TIN (identifikationsnummer) i butiken.

Låt oss välja attributet "INN" som den primära nyckeln. Vidare kommer detta attribut att användas för att organisera länkar mellan tabellerna "Butiker" och "Ägare" (dessa länkar bör återspegla det verkliga förhållandet mellan butiker och deras ägare).

Låt oss bestämma nycklarna för tabellen "Ägare".

Om det var möjligt att anta att det inte finns några namnar bland butiksägarna, kunde attributet "Efternamn" för det aktuella förhållandet väljas som nyckel. Men tyvärr kan butiksägare inte bara vara namnar, utan också fullständiga namn (osannolikt, men mycket möjligt). Därför kan du välja ägarens passdata som nyckel, dvs. använd en sammansatt nyckel för att identifiera den, inklusive attributen "Serie" och "Nummer". Denna nyckel kommer att betraktas som primär. Med dess hjälp kommer vi att upprätta en koppling mellan ägaren och hans butiker.

Primära nycklar ger inte bara otvetydighet när du söker efter information (de är unika), utan också att du kan länka data i två tabeller.

Låt oss definiera typen av förhållande mellan tabellerna "Butiker" och "Ägare".

Om vi \u200b\u200bantar att en person kan äga flera butiker, men varje butik har en enda ägare, bör ett förhållande en till många upprättas mellan dessa tabeller. För att organisera en sådan anslutning i databasen skulle det vara möjligt att inkludera i tabellraden "Butiker" som innehåller information om butiken extern nyckelidentifiera butiksägaren, dvs. uppgifterna för hans pass - attribut "Series" och "Number". I det här fallet är det omöjligt att organisera en anslutning genom att inkludera "INN" -nyckeln som identifierar butiker som en utländsk nyckel i tabellen "Ägare", eftersom i detta fall information om ägaren måste dupliceras för varje butik.

Om man antar att en person bara kan äga en butik, men varje butik kan ha flera ägare, är resultatet ett förhållande en till många, men i detta fall extern nyckel (TIN i butiken) måste inkluderas i tabellen med information om ägarna.

I verkligheten kan varje person vara ägare till flera butiker och varje butik kan ha flera ägare. Därför måste ett förhållande mellan många och många mellan tabellerna Butiker och ägare upprättas, för den organisation som en speciell tabell skapas som beskriver förhållandena mellan butiker och ägare:

"Butiker-ägare"

VÄRDSHUS

Serier

rum

Denna tabell gör det möjligt att hitta alla butiksägarna som använder "TIN" -attributet i butiken (genom uppgifterna om deras pass), och att använda det sammansatta attributet, som innehåller attributen "Serie" och "Nummer" i ägarens pass, i databasen alla butiker som han äger.

För att göra detta, skapa en tabell "Butiker-ägare", upprätta en-till-många förhållanden mellan tabellen "Butiker" och "Butiker-ägare" -tabellen, liksom mellan "Ägare" och "Butiker-ägare" -tabellerna:

VÄRDSHUS Serier rum

"Butiker-ägare"

De etablerade relationerna hjälper DBMS att upprätthålla informationens integritet och konsekvens. Till exempel kan du ställa in reglerna för uppdatering av information i relaterade tabeller när du uppdaterar information i huvudtabellen (när en butik likvideras, till exempel måste information om den från databasen tas bort och överföras till arkivet, och inte bara raden från tabellen "Butiker", utan all information (Se tillhörande tabeller för den butiken).

För att göra det lättare för användarna att accelerera sökningen i DBMS kan du inte bara söka med unika nycklar. Till exempel kan du i tabellen hitta alla butiker med samma namn eller alla butiker som ägs av samma ägare.

Normalisering av data ledde till uppdelningen av tabeller, fördelningen av relationer "primär nyckel-främmande nyckel" i mindre tabeller. Resultatet av normalisering är en minskning av dataredundans - du behöver inte längre kopiera data om varje ägare för varje butik.

Andra normala formen kräver att alla icke-nyckelkolumner beror på dess primära nyckel (och på hela nyckeln, inte av dess enskilda komponenter). En relation har en andra normalform om den motsvarar den första normala formen och inte innehåller ofullständiga funktionella beroenden. Ofullständigt funktionellt beroende bestäms av två villkor: relationens nyckel definierar funktionellt något icke-nyckelattribut och en del av nyckeln definierar funktionellt samma icke-nyckelattribut.

En relation som inte motsvarar den andra normala formen kännetecknas av redundans av lagrade data.

I det här exemplet görs uppsättningen relationsattribut och valet av nycklar på ett sådant sätt att tabellerna motsvarar den andra normala formen. Om denna korrespondens inte fanns, för att föra tabellerna till andra normala former, skulle det vara nödvändigt att separera duplikatinformationen (del av nyckeln och de icke-nyckelattribut som bestämts av den) i en separat tabell.

Till exempel: det är nödvändigt att lagra information om varor som levereras till butiker i databasen. Denna information inkluderar attributen "Namn", "Kod" och "Pris" för artikeln, samt "Kvantitet" på det levererade objektet. Om du inkluderar den här informationen i tabellen Leveranser i följande vy:

"leveranser"

(här "INN" identifierar den butik som leveransen levereras till (detta är en utländsk nyckel som används för att skapa ett en-till-många-förhållande mellan tabellen "Butiker" med denna tabell), "Namn" är produktens namn, "Kod" är dess unika kod (varor med olika egenskaper och därför olika priser kan ha ett namn, men koderna kommer att vara annorlunda), "Pris" - försäljningspriset för varorna, "Kvantitet" - mängden levererade varor), då kan överflöde uppstå.

För att definiera en sträng som representerar leverans av varor till en specifik butik kan du ange en sammansatt nyckel som innehåller attributen "INN" och "Kod". Denna information gör det möjligt att bestämma priset på produkten och dess kvantitet som levereras till den givna butiken, samt beräkna den totala kostnaden för produkten. Om vi \u200b\u200bantar att varorna levereras till alla butiker till samma pris och priset inte ändras över tid, bestäms icke-nyckelattributet "Pris" inte bara av den sammansatta nyckeln "INN" + "Kod", utan också av dess del - attributet "Kod" ". Således upprepas samma pris i alla rader i tabellen, som innehåller information om leveransen av samma produkt. Detta leder till redundans. Produktens namn bestäms också av dess kod. Därför kan information som endast är relaterad till produkten och inte beroende på butiken placeras i en separat tabell:

Här kommer nyckelfältet "Kod" att låta dig koppla data i tabellen "Leveranser" med data från tabellen "Produkter"

Således eliminerade reduktionen till den andra normala formen redundansen genom att tilldela nya tabeller: "Leverans" -tabellen är uppdelad i två tabeller "Leveranser" och "Varor", mellan vilka en länk upprättas.

Tredje normalform ytterligare ökar kraven: förhållandet motsvarar den andra normala formen och det finns inga övergående funktionella beroenden bland dess attribut (ingen icke-nyckelkolumn ska bero på en annan icke-nyckelkolumn, den kan bara bero på den primära nyckeln).

I exemplet som behandlas skulle skillnaden i den tredje normala formen visas om följande villkor är uppfyllda: alla varor med samma namn har samma pris (namnet bestäms av koden och priset - med varornas namn). I det här fallet skulle det finnas överflöd, eftersom priset för ett visst produktnamn skulle upprepas så många gånger som det finns olika koder för den här produkten.

Det skulle vara möjligt att bli av med redundans genom att dela upp tabellen "Produkter" i två tabeller (en skulle inkludera attributen "Kod" och "Namn", och den andra "Namn" och "Pris").

Men i exemplet som beaktas är situationen annorlunda: varor har olika koder, om deras egenskaper är annorlunda bör priserna också skilja sig åt.

Fjärde normalform tillåter oberoende en-till-många-förhållande mellan nyckel- och icke-nyckelkolumner. Enkelt uttryckt kan du inte lägga heterogen information i en tabell, dvs. data mellan vilka det inte finns någon direkt anslutning.

Denna regel kan ses i följande exempel. Kundrelationschefen avser att använda information om familjemedlemmarna till butiksägarna för att utföra sina uppgifter. Denna information bör inte inkluderas i ägartabellen, eftersom det är svårt att bestämma hur mycket utrymme att reservera i raderna på bordet för specifika personer att lagra sin äktenskapliga status - en kan vara ensam och den andra en far med många barn. Information om familjemedlemmar bör placeras i en separat tabell, där varje rad innehåller information om en familjemedlem, inklusive en utländsk nyckel som identifierar butiksägaren för att upprätta en länk till tabellen Ägare.

Femte normala formen slutför vanligtvis normaliseringsprocessen. I detta skede är alla tabeller uppdelade i minimala delar för att eliminera redundans. Varje bit av icke-nyckeldata i tabeller bör bara visas en gång. Detta eliminerar problemen med uppdatering av information i databasen: alla ändringar av information som inte är nyckel måste göras endast en gång, vilket ger möjlighet att hantera dataintegritet.

Databasdesignprocessen är ett mycket viktigt steg i utvecklingen av informationssystem. Det är designkvaliteten som till stor del bestämmer effektiviteten i att använda databasen.

För närvarande används specialverktyg för att underlätta utvecklingen av informationssystem (CASE-verktyg - datorstödd programvara / systemteknik).

Frågor för självkontroll:

1. Vad är en databas?

2. Vad är extern presentation av data?

3. Vad är kärnan i konceptuell datarepresentation?

4. Vad är en datamodell?

5. Vad är normalisering?

6. Vad är relationens nyckel?

7. Vilken nyckel kallas extern?

8. Vilken typ av anslutningar kan organiseras i databasen?

9. Vad är kärnan i var och en av de fem normala formerna?

Självstudieuppgift:

Designa databaserna hos ett kundserviceföretag. Databasen behövs av tre anställda i företaget. Den första av dem handlar om redovisningen av de tjänster som tillhandahålls av företaget och behöver följande information:

Den andra anställden samlar in information om artisterna och är intresserad av:

Den tredje anställden arbetar med kunder och det är viktigt för honom att veta.

Relationsmodelldata (RMD) för ett visst ämnesområde är en uppsättning relationer som förändras över tid. När du skapar ett informationssystem låter en uppsättning relationer lagra data om objekt i ämnesområdet och simulera anslutningar mellan dem.

En relationsdatabas är ett datalager som innehåller en uppsättning av tvådimensionella tabeller. Uppgifterna i tabellerna måste följa följande principer.

1. Attributvärden (kolumn, fält) måste vara atomiska (med andra ord, alla värden i skärningspunkten mellan en rad och en kolumn får inte delas upp i flera värden).

2. Värdena för varje fält måste vara av samma typ.

3. Varje post i tabellen är unik.

4. Varje fält har ett unikt namn.

5. Sekvensen av fält och poster i tabellen är inte nödvändig

Attitydär det viktigaste konceptet och är en tvådimensionell tabell som innehåller vissa data.

Essensen är ett objekt någrakaraktär, data om vilka lagras i databasen. Enhetsdata lagras i en relation.

Attribut är egenskaper som karakteriserar en enhet. I tabellstrukturen heter varje attribut och har motsvarande kolumnrubrik.

Nyckelförhållandeuppsättningen av dess attribut kallas, som unikt identifierar var och en av relationens tuplar.

Nycklar används ofta för följande ändamål:

Eliminering av duplicerade värden i nyckelfält;

Beställer poster. Det är möjligt att beställa i stigande eller fallande ordning av värdena för alla nyckelfält, samt blandad beställning (med en - ökning och av andra - minska);

Organisationer av länkande tabeller.

Begreppet en utländsk nyckel är viktigt. En utländsk nyckel kan definieras som många attribut för en relation R2, vars värden måste matcha värdena för en möjlig nyckel i en annan relation R1.

Ett operativsystem kan tillämpas på relationer, vilket gör att man kan få en relation från en annan. Till exempel kan resultatet av en fråga till en relationsdatabas vara en ny relation beräknad baserad på befintliga relationer. Därför är det möjligt att dela upp behandlade data i lagrade och beräknade delar. Huvudenheten för databehandling i relationella databaser är en relation, inte dess enskilda tuplar (poster).

Att designa databaser över informationssystem är en ganska besvärlig uppgift. Det utförs på grundval av att formalisera strukturen och processerna inom ämnesområdet, information om vad som ska lagras i databasen. Skilja på konceptuelloch schematisk strukturelldesign.

Konceptuell design av en IS DB är till stor del en heuristisk process. Tillfredsställandet av den infologiska modellen för ämnesområdet som byggs inom dess ramverk bekräftas empiriskt i processen för IS-funktion.

Låt oss lista stadierna i konceptuell design:

Studie av ämnesområdet för att skapa en allmän förståelse av det;

Urval och analys av funktioner och uppgifter för det utvecklade IS;

Bestämning av ämnesområdets huvudsakliga objekt och relationer mellan dem

Formaliserad representation av ämnesområdet.

Vid utformning av ett relationsdatabasschema kan följande procedurer särskiljas:

Bestämning av listan över tabeller och förhållanden mellan dem;

Bestämning av listan över fält, fälttyper, nyckelfält i varje tabell (tabellschema), upprättande av länkar mellan tabeller genom utländska nycklar;

Upprätta indexering för fält i tabeller;

Utveckling av listor (ordböcker) för fält med uppräknade data;

Upprätta integritetsbegränsningar för tabeller och relationer;

Normalisering av tabeller, korrigering av tabellen och länkar.

Databasdesign utförs på fysiska och logiska nivåer. Design på fysisk nivå utförs med hjälp av ett DBMS och är ofta automatiserat.

Logisk design består i att bestämma antalet och strukturen på tabeller, utveckla frågor till databasen, rapportera dokument, skapa formulär för att mata in och redigera data i databasen etc.

En av de viktigaste uppgifterna för logisk databasdesign är datastrukturering. Följande metoder för utformning av datastrukturer skiljer sig:

Kombinera information om entitetsobjekt inom en tabell (ett förhållande) med efterföljande sönderdelning i flera sammankopplade tabeller baserat på normalisering av relationer;

Formulering av kunskap om systemet (definition av typer av initiala data och relationer) och krav för databehandling, erhållande av ett färdigt databasschema eller till och med ett färdigt applikationsinformationssystem med ett CASE-system;

Implementering av systemanalys och utveckling av strukturella modeller.

Skicka ditt bra arbete i kunskapsbasen är enkelt. Använd formuläret nedan

Studenter, doktorander, unga forskare som använder kunskapsbasen i sina studier och arbete kommer att vara mycket tacksamma för er.

Publicerat den http://www.allbest.ru/

Testa

Relationsdatabasdesign

• Normalisering av relationer
• Funktionella beroenden
• Boyes-Codd normal form
• Litteratur

Relationsdatabasdesign

Huvudmålet med databasdesign är att minska redundansen för lagrade data, och följaktligen att spara mängden minne som används, att minska kostnaden för flera operationer för att uppdatera redundanta kopior och för det första eliminera möjligheten till inkonsekvenser på grund av lagring av information om samma volym på olika platser. samma objekt. Redundans innebär att vissa data eller grupper av data kan upprepas många gånger.

Under databasdesignprocessen kan följande problem uppstå:

Uppdatera avvikelser - på grund av dataredundans, vid uppdatering av data, är det nödvändigt att se alla data, men det kan finnas en situation då inte all data uppdateras (potentiell datakonsekvens).

Inklusive avvikelser - det är möjligt att informationen inte kan matas in i databasen innan ytterligare information tas emot och matas in.

Avlägsna avvikelser - det motsatta problemet kan uppstå när vissa data tas bort (förlust av användbar information är möjlig).

Antalet Null-värden har inte minimerats. Förutom redundans är nollor en källa till potentiella problem i relationella databaser, eftersom det är omöjligt att avgöra vad de betyder. Därför bör deras användning minimeras.

De tre första problemen löses i processen för att normalisera relationerna.

relationellt basellt funktionellt beroende

Normalisering av relationer

Normalisering är en partition (eller nedbrytning) av en tabell i två eller fler, som har bättre egenskaper när du lägger till, modifierar och raderar data. Det ultimata målet med normalisering är att ha en "ren" databasdesign där " varje faktum hålls endast i ett plats" , d.v.s. dataredundans elimineras. Detta görs inte så mycket för att spara minne, men för att eliminera eventuell inkonsekvens i lagrad data.

Varje tabell i en relationsdatabas uppfyller villkoret att det alltid finns ett enda atomvärde i skärningspunkten mellan varje rad och kolumn i en tabell, och det kan aldrig finnas flera sådana värden. Alla tabeller som uppfyller detta villkor kallas normaliserad... Faktum är att icke-normaliserade tabeller, det vill säga tabeller som innehåller upprepade grupper, inte ens beaktas i en relationsdatabas.

Den normaliserade tabellen matchar den första vanligt form, förkortat till 1NF. Således betyder "normaliserat" och "att vara i 1NF" samma sak för tabellen. I praktiken används dock ofta termen "normaliserad" i en smalare bemärkelse - "helt normaliserad", vilket innebär att projektet inte bryter mot några normaliseringsprinciper.

Nu, förutom 1NF, kan ytterligare nivåer av normalisering definieras - den andra normala formen (2NF), den tredje normala formen (3NF), etc. Det anses att en tabell finns i 2NF om den är i 1NF och uppfyller dessutom ett visst ytterligare villkor, vars essens kommer att beaktas nedan. En tabell finns i 3NF om den är i 2NF och dessutom uppfyller ytterligare ett ytterligare villkor etc.

Således är varje normal form i viss mening mer begränsad, men också mer önskvärd än den föregående. Detta beror på det faktum att (n + 1) - i normal form inte har några av de oattraktiva särdragen i den n normala formen. Den allmänna betydelsen av det ytterligare villkor som åläggs den (n + 1): e normala formen med avseende på den n: e normala formen är att eliminera dessa oattraktiva särdrag.

Förfarandet för att normalisera relationer är reversibelt. Till exempel kan en uppsättning förhållanden i 3NF konverteras till relationer i 2NF. Denna mycket viktiga egenskap av normalisering innebär att ingen information går förlorad under normaliseringsprocessen.

Normaliseringsteori baseras på förekomsten av vissa beroenden mellan tabellens fält. Särskild uppmärksamhet ägnas åt funktionella och flervärde- och anslutningsberoenden.

Funktionella beroenden

Låt X och Y vara godtyckliga underuppsättningar av uppsättningen attribut för relationen R. Y beror funktionellt på X om och bara om varje värde i uppsättningen X är associerat med exakt ett värde för uppsättningen Y. Notation: XY (läs som "X definierar funktionellt Y"). De vänstra och högra delarna av den symboliska posten kallas för determinanten respektive den beroende delen.

Fikon. 1. Tabell över POS-tillbehör

Med andra ord, om två tupler i relationen R sammanfaller i värdet av X, kommer de också att sammanfalla i värdet av Y. För klarläggning, överväg den som visas i fig. 1 är en något modifierad version av leveransbordet som visas i fig. 2.

Alla tuplar i PIC-relationen med samma värde på P # -attributet har samma värden som Hor-attributet. Detta innebär att attributen för bergen funktionellt beror på attributen №: (№) (berg). Dessutom finns det i detta avseende andra permanenta funktionella beroenden: (P-nummer, D-nummer) (Col), (P-tal, D-nummer) (Gore), (P-tal, D-nummer) (Gore, Col), (P №, №, (№), (П, №) (№, №, Gor, Kol), liksom beroenden som är funktionella vid varje ögonblick, men inte hela tiden, till exempel, (P Nej. (Antal).

Observera att om X är en potentiell nyckel för R, måste alla Y-attribut för R vara funktionellt beroende av X (detta är en konsekvens av definitionen av en potentiell nyckel). I själva verket, om förhållandet R uppfyller det funktionella beroendet AB och A inte är en potentiell nyckel, kommer R att kännetecknas av vissa redundans... I förhållande till en PIC kommer till exempel informationen som varje leverantör finns i en viss stad att upprepas många gånger.

Funktionella beroenden är integritetsbegränsningar och måste kontrolleras varje gång databasen uppdateras. Ett uppenbart sätt att minska många funktionella beroenden är att utesluta trivial beroenden, d.v.s. de som inte kan misslyckas med att uppfyllas Till exempel (П, №) (№). Funktionellt beroende är trivial om och bara om den högra sidan av teckennotationen är en delmängd av vänster sida. Sådana beroenden är inte av praktiskt intresse.

När man analyserar relationer ges en speciell roll oreducerbar beroenden... Ett attribut B är oåterkalleligt beroende av ett sammansatt attribut A om det funktionellt beror på A och inte beror funktionellt på någon delmängd av attributet A. I tidiga publikationer istället för termen oreducerbar beroende termen användes komplett funktionell beroende.

Funktionella beroenden kan beskrivas med hjälp av diagram. För leverantörs- och reservdatabasen (figur 1) visas schemat för funktionsberoende i figur 2.

Varje pil i diagrammet börjar med primärnyckeln för motsvarande relation. Andra pilar är möjliga i diagrammet. I detta fall kan normaliseringsproceduren informellt karakteriseras som en procedur för att eliminera pilar som inte startar vid primärnyckeln.

Normala former baserade på funktionella beroenden

Vi nämnde den första normala formen (1NF). Låt oss ge en striktare definition av det, liksom definitioner av andra normala former.

En tabell är i första normala formen (1NF) om och bara om ingen av dess rader innehåller mer än ett värde i något av dess fält och inget av dess nyckelfält är tomt.

Till exempel uppfyller tabellen som visas i fig. 3 inte dessa krav (data i fältet D # är inte atomiskt):

Fikon. 3. Ett exempel på en tabell som inte är en relation

Sådana tabeller beaktas inte ens i relationella modeller.

Om vi \u200b\u200butvecklar en relationsdatabas kan man i det första steget skapa en tabell som kombinerar all information i fråga, till exempel leverantörer, delar, leveranser. Tabellen i figur 3 representerar ett giltigt relationellt förhållande. Han heter universell attityd den projicerade databasen. En generisk relation innehåller alla attribut som är intressanta och kan innehålla all data som är avsedd att lagras i databasen i framtiden. För små databaser kan den generiska relationen användas som utgångspunkt i deras design. Tabellens primära nyckel är en kombination av P # och D # fälten. Denna tabell uppfyller alla krav i 1NF.

				Dosimeter
				Radiometer
				Dosimeter
				Dosimeter
				Dosimeter

Fikon. 4. Förhållande i första normala form

Diagrammet över funktionella beroenden av en sådan relation har den form som visas i fig. 4 (vi antar att leverantörens status bestäms av staden).

Det aktuella förhållandet, som är i 1NF, har en struktur som av någon anledning inte är helt önskvärd. Till exempel är uppsägning av information uppenbar. Detta leder inte bara till en ökning av databasens storlek utan också till olika avvikelser:

Föra in. Det är omöjligt att infoga data om leverantören (P5) utan att ange delen (Nollvärde i nyckelfältet är inte tillåtet).

Radera. När du tar bort en tupel måste du ta bort för mycket annan information (om du raderar leveransinformation raderas leverantörsinformationen).

Uppdatering. Överdriven information kan leda till inkonsekventa resultat. Om leverantör P1 har flyttat till en annan stad, och uppdateringen inte görs i alla tuplar, kommer databasen att innehålla motstridig information.

Dessa avvikelser kan elimineras genom att förhållandet till andra normala former genom att dela det i två.

En tabell är i andra normala former (2NF) om den uppfyller definitionen av 1NF och alla fält som inte ingår i den primära nyckeln är oåterkalleliga beroende av den primära nyckeln (eller är i fullt funktionellt beroende av den primära nyckeln).

De funktionella beroenden av förhållandena i vår databas, reducerad till 2NF, visas i fig. 4, och motsvarande tabeller visas i fig. fem.

Nu kan du ange information om leverantörer i databasen utan information om deras produkt, när du tar bort information om en produkt återstår resten av uppgifterna (om till exempel leverantörer), information om staden inträffar en gång och detta tar bort problemet med informationsredundans. Det är, tack vare nedbrytningen, fick vi bort många av de problem som fanns i relation till 1NF. Samtidigt kan relationerna som visas i fig. 5 slås samman och sedan återgår vi till relationen som visas i fig. 3 - detta innebär att sönderdelningen utfördes utan dataförlust.

Således, först skede förfaranden normalisering relationer är en varelse utsprång för undantag " citerad" funktionell beroenden.

Fikon. 7. Relationer i 2NF

Strukturen för relationerna som visas i figur 7 kan emellertid skapa några problem med leverantörsrelationen, där de icke-nyckelattributen inte är ömsesidigt oberoende. Beroendet av attributet Status på attributet П№ är funktionellt och oåterkalleligt, men detta beroende är det också transitiv genom attributet Stad - varje P№-värde definierar stadsvärdet och varje stadsvärde definierar statusvärdet. Men om beroenden AB och BC uppfylls, uppfylls också beroendet AC. Transitiva beroenden kan återigen leda till uppdaterade avvikelser:

Infoga - du kan inte inkludera data om en viss stad och dess status förrän det finns en leverantör i den.

Radering - när man raderar en leverantör går information om stadens status förlorad (det är uppenbart att orsaken till ett sådant problem är gemensam information - tabellen innehåller information om både leverantörer och staden).

Uppdatering - städernas status upprepas flera gånger. När du ändrar en stads status måste du titta igenom många rader för att undvika att få ett inkonsekvent resultat, men sannolikheten för fel kvarstår.

Problemet löses genom att reducera relationen Leverantör till tredje normal form genom dess nedbrytning:

Denna procedur eliminerar transitivt beroende och löser alla svårigheter.

Attityd belägen i tredje vanligt form (3NF) sedan och endast sedan, när den belägen i 2NF och varje icke-nyckel attribut icke-transitivt beror från primär nyckel.

Med andra ord: tabell belägen i tredje vanligt form (3NF), om en den belägen i 2NF och inte heller en sak av henne icke-nyckel fält inte beror funktionellt från några annan icke-nyckel fält.

Således, andra skede normalisering är en varelse utsprång för undantag transitiv beroenden.

I processen att utföra normaliseringsproceduren uppstår ofta situationer när en relation kan sönderdelas på flera sätt. Till exempel förhållandet Leverantör (Fig. 7) med funktionella beroenden ПCity och CityStatus och därför transitivt beroende № Status. Det finns möjliga varianter av sönderdelning av detta förhållande till två projektioner belägna i 3NF:

A: (P #, City) och (City, Status) (som tidigare föreslagits) och B: (P #, City) och (P #, Status)

Den tredje varianten av sönderdelning på projektionen (П№, Status) och (City, Status) kan inte tillämpas, eftersom den utförs med förlust av information - flera städer kan ha samma status, då kommer information om staden där leverantören ligger förloras.

Av någon anledning är sönderdelning B mindre önskvärt än sönderdelning A. Till exempel efter att sönderdelning B har utförts är det omöjligt att infoga information om att en viss stad har en viss status utan att ange en leverantör från den staden.

Vid sönderdelning A är båda projektionerna oberoende av varandra i den meningen att uppdateringar i vart och ett av projektionerna kan utföras helt oberoende av varandra. Vid sönderdelning B måste uppdateringen av någon av de två projektionerna kontrolleras så att det ursprungliga CityStatus-beroendet inte bryts. Det vill säga, prognoserna för nedbrytning B är inte oberoende av varandra.

Begrepp oberoende utsprång ger ett kriterium för att välja en av flera möjliga sönderdelningar. Projektionerna R1 och R2 för relationen R är oberoende i ovanstående mening om och bara om

Varje funktionellt förhållande i förhållande till R är en logisk konsekvens av funktionella beroenden i prognoserna R1 och R2;

De gemensamma attributen för projektioner R1 och R2 utgör en potentiell nyckel för minst en av dem.

I detta exempel, i sönderdelning A, är två projektioner oberoende, eftersom deras gemensamma attribut City är en potentiell nyckel för den andra projektionen, och varje funktionellt beroende av det ursprungliga förhållandet bevaras i projektionerna. Tvärtom, i nedbrytning B är två prognoser inte oberoende, eftersom CityStatus-beroendet kan inte härledas från funktionella beroenden för dessa projektioner, även om deras gemensamma attribut P # är en potentiell nyckel för båda projektionerna.

Idén om normalisering med nedbrytning till oberoende projektioner föreslogs av Rissanen och kallas sönderfall från bevara beroenden.

Boyes-Codd normal form

Hittills har vi för enkelhets skull antagit att varje förhållande endast har en potentiell nyckel, den primära nyckeln. Definitionen av 3NF som anges ovan passar inte riktigt om

- förhållandet har två eller flera potentiella nycklar;

- två potentiella nycklar är komplexa och överlappar varandra (har minst ett gemensamt attribut).

Därför kompletterades definitionen av 3NF vanligt form Boyes-Codd (Boyce-Codd) - NFBC... Det kan formuleras enligt följande:

Attityd belägen i vanligt form Boyes-Codd sedan och endast sedan, när determinanter är potential nycklar.

Med andra ord, i ett funktionsdiagram bör pilar endast börja med potentiella nycklar.

Kombinationen av sådana förhållanden stöter inte ofta i praktiken, därför är relationer utan sådana förhållanden likvärdiga med 3NF och NFBK.

Låt oss ge ytterligare en definition: Tabell belägen i vanligt form Boyes-Codd (NFBC), sedan och endast sedan, när några funktionell beroende mellan henne fält kommer ner till oreducerbar funktionell beroenden från potential nyckel.

Tänk på ett exempel som innehåller två kandidatnycklar som inte överlappar varandra:

Leverantör (P #, Namn_P, Status, Stad),

där attributen П№ och Name_П är potentiella nycklar och attributen Status och City är helt oberoende. Funktionsberoende-diagrammet visas i fig. 8. Detta förhållande finns i NBFK. Här är alla determinanter potentiella nycklar och alla pilar börjar med potentiella nycklar.

Här är exempel på förhållanden där potentiella nycklar överlappar varandra.

Första exemplet: Supply Ratio (P #, Name_P, D #, Qty).

Det finns viss redundans i detta avseende som orsakar uppdateringsavvikelser. Potentiella nycklar här är (P #, D #) och (Name_P, D #), och P # och Name_P definierar varandra varandra. Detta förhållande är inte i andra normala former och kan delas upp i två projektioner (№, Namn_П) och (№, №,, antal) för att erhålla oreducerbara funktionella beroenden. Men samma nedbrytning kan föreslås under antagandet att förhållandet inte finns i NBFK, eftersom innehåller två determinanter som inte är potentiella nycklar (П№ och Name_П är determinanter, eftersom de definierar varandra):

Leverantör (P #, Namn_P) och leverans 1 (P #, D #, Antal).

Andra exempel: Attitude SDP (S, D, P),

där attribut står för studenter, discipliner och lärare. Tupeln för SDP-relationen innebär att någon student C studerar någon disciplin D från någon lärare P. Samtidigt finns det begränsningar:

- Varje student studerar detta ämne med en lärare;

- Varje lärare undervisar bara ett ämne (men varje ämne kan läsas av flera lärare).

Beroende (S, D) P följer från den första begränsningen och från den andra - PD. Figur 9 visar ett exempel på en tabell och ett diagram över de funktionella beroenden för en sådan relation. I det här exemplet finns det två överlappande potentiella nycklar - (S, D) och (S, P). Förhållandet finns i 3NF (det transitiva förhållandet som finns här handlar om nyckelattributet) men finns inte i NFBC och har några uppdateringsavvikelser. Om vi \u200b\u200btill exempel tar bort informationen om att Oleg studerar fysik förlorar vi information om att Petrov undervisar i fysik. Detta problem orsakas av det faktum att P är en determinant, men inte en potentiell nyckel. För att lösa detta problem måste den första relationen delas upp i två prognoser: SP och DP.

Således tillåter NFBK-konceptet att bli av med några av de problem som finns i relationer i 3NF. Definitionen av NFBK är enklare än definitionen av 3NF, eftersom den använder inte begreppen normala former, primär nyckel och transitivt beroende. Dessutom kan begreppet en potentiell nyckel ersättas av införandet av ett mer grundläggande begrepp om funktionellt beroende. Men å andra sidan begreppen primär nyckel, transitivt beroende, etc. är användbara i praktiken eftersom de ger en uppfattning om en steg-för-steg-process följt av en utvecklare för att tvinga ett godtyckligt förhållande till en motsvarande uppsättning av relationer i NFBC.

Normala former som stöds av mer komplexa beroenden

Fikon. 10. Onormaliserat DPU-förhållande

I följande normala former (4NF och 5NF) beaktas inte bara funktionella utan också flervärdesberoenden och anslutningsberoenden mellan relationens attribut. För att lära känna dem, tänk på det onormaliserade förhållandet som visas i figur 10. Varje relationstupel innehåller ett disciplinnamn, en grupp instruktörnamn och en uppsättning läroböcker. Detta innebär att varje kurs kan läsas av alla lärare som använder läroböcker. Låt oss förvandla denna relation till en motsvarande normaliserad relation. För de uppgifter som presenteras definieras inte funktionella beroenden. Därför finns det ingen formell grund för nedbrytningen av detta förhållande och det normaliserade förhållandet visas i fig. elva.

		Mekanik
		Mekanik
Matte		Geometri
Matte		Matta. analys

Fikon. 11. Normaliserat DPU-förhållande

Fikon. 12. Projektioner (D, P) och (D, U) för DPU-förhållandet

Det är uppenbart att DPU: s förhållande kännetecknas av betydande redundans och leder till förekomsten av uppdateringsavvikelser, till exempel när man lägger till en ny lärare måste man ange en tupel för varje lärobok. Emellertid är inställningen helt nyckeln och är därför i NBFK. Problemen som uppstår orsakas av att lärare och läroböcker är helt oberoende av varandra. Problemet med det normaliserade DPU-förhållandet skulle inte ha uppstått om alla oberoende upprepande grupper initialt hade separerats. I vårt fall var det möjligt att förbättra situationen genom att ersätta DPU-förhållandet med projektionerna (D, P) och (D, Y) (Fig. 12). I det här fallet är båda projektionerna helt nyckeln och finns i NFBK, och deras anslutning ger den ursprungliga tabellen, det vill säga nedbrytningen utförs utan förlust. Denna sönderdelning kan inte utföras baserat på funktionella beroenden som inte finns i detta exempel. Det kan implementeras på basis av ett flervärdat beroende. Flervärda beroenden är en generalisering av funktionella beroenden i den meningen att varje funktionellt beroende är multivaluerat, i vilket den beroende delen är en singletonuppsättning.

När det gäller DPU finns det två flervärda beroenden: DP och DP.

Den första av dessa flervärde beroenden innebär att även om det för varje disciplin inte finns någon lärare som bara motsvarar denna disciplin, dvs. DP: s funktionsberoende uppfylls inte, men varje disciplin har en viss uppsättning lärare, oavsett titel på läroboken.

Det andra flervärde beroendet tolkas på liknande sätt.

Låt vara OCH, FÖRE KRISTUS är slumpmässig underuppsättningar skaror attribut relationer R. I tvetydigt beror från OCH (OCH I) sedan och endast sedan, när ett gäng värden I, lämplig given par värden (OCH, FRÅN) relationer R, beror endast från OCH, men inte beror från FRÅN.

Det är uppenbart att det flervärda beroendet AB uppfylls endast när det flervärda beroendet AC uppfylls. Flervärda beroenden bildar alltid anslutna par: AB || C.

När vi återgår till problemen med DPU-förhållandet kan vi säga att de är förknippade med förekomsten av flervärda beroenden som inte är funktionella (det är närvaron av sådana beroenden som kräver att två tupler införs när det är nödvändigt att lägga till data om en annan fysiklärare). Projektionerna (D, P) och (D, Y) innehåller inte flervärda beroenden och är därför mer önskvärda. Innan vi definierar den fjärde normala formen, låt oss bekanta oss med R. Fagins teorem:

Låt A, B, C vara attributuppsättningarna för relationen R (A, B, C). Förhållandet R kommer att vara lika med anslutningen mellan dess prognoser (A, B) och (A, C) om och bara om de flervärdesberoende AB och AC är uppfyllda för förhållandet R.

Attityd R belägen i fjärde vanligt form (4NF) sedan och endast sedan, när i fall existens tvetydig beroenden EN B allt resten attribut R funktionellt bero från EN.

Med andra ord:

Attityd R belägen i 4NF, om en den belägen i NFBC och allt tvetydig beroenden relationer R faktiskt är funktionell beroenden från potential nycklar.

DPU-förhållandet finns inte i 4NF, eftersom det innehåller ett flervärdat beroende som inte är ett funktionellt beroende. Båda projektionerna (D, P) och (D, Y) finns dock i 4NF, vilket, i jämförelse med NFBK, låter dig skapa en förbättrad struktur.

Observera att konceptet med oberoende Rissanen-projektioner baserade på funktionella beroenden (relationen R (A, B, C) som uppfyller de funktionella beroenden A\u003e B och B\u003e C bör delas upp i projektioner (A, B) och (B, C), och inte (A, B) och (A, C)), är också tillämpligt på valet av sönderdelningsväg, om det i stället för funktionella beroenden finns flervärda beroenden A \u003e\u003e B och A \u003e\u003e C. I detta fall är det nödvändigt att genomföra en sönderdelning i relationerna (A, B) och (A, C).

I alla normaliseringsförfaranden som beaktades fram till denna tid, sönderdelades en relation i två. Ibland kan detta inte göras, men det är möjligt att sönderdelas till ett större antal relationer, som var och en har bättre egenskaper. En sådan relation kallas en n-nedbrytbar relation, för vilken n\u003e 2.

Tänk till exempel relationen P-D-Pr (leverantörer-detaljer-projekt) (fig. 13). Samma leverantör kan leverera flera typer av delar för olika projekt. Den primära nyckeln till detta förhållande är den kompletta uppsättningen av dess attribut, det finns inga funktionella och flervärda beroenden (det finns inget flervärdsberoende, eftersom för P1 är uppsättningen av delar beroende av projektet). Därför är förhållandet i 4NF. Emellertid kan det förekomma anomalier (inte alltid uppenbara) i det, som kan elimineras genom sönderdelning i tre relationer (sönderdelning i två relationer är omöjligt, eftersom den omvända operationen inte tillåter att återgå till den ursprungliga relationen). Dessutom beror nedbrytningsgraden på tuplorna. Om till exempel en av de tre första tuplen i den initiala relationen tas bort eller en tupel (P2, D1, Pr2) läggs till, kan den delas upp i två projektioner. Om vi \u200b\u200bi den första relationen tar bort den sista tupeln eller ersätter den med en tupel (P2, D1, Pr2), kan den inte delas in i två eller tre projektioner utan att kränka dataintegriteten. Nedbrytbarheten av detta förhållande kan vara en grundläggande och tidsoberoende egenskap om du lägger till en ytterligare begränsning.

Uttalandet att PDPr är lika med kombinationen av tre projektioner PD, DPr, PrP motsvarar följande påstående:

OM paret (P1, D1) tillhör relationen PD

Ipara (D1, Pr1) tillhör relationen DPr

Ipara (Pr, 1P1) tillhör förhållandet PrP,

Tripletten (P1, D1, Pr1) tillhör relationen PDPR.

Detta är uppenbart, eftersom trippeln P1, D1, Pr1 är i samband med projektionerna PD, DPr, PrP. Samtalet är också alltid sant.

Å andra sidan är det sant att paret (P1, D1) är närvarande i förhållande till PD, om trippeln (P1, D1, Pr2) är närvarande i förhållande till PDP, är paret (P1, Pr1) i förhållande till PP, om (P1, D2, Pr1) är i PDP, och paret (D1, Pr1) är i förhållande till PD, om (P2, D1, Pr1) är i PDP. Sedan, om vi tar hänsyn till vårt första uttalande, måste det i detta förhållande också finnas en tupel (P1, D1, Pr1)! Detta betyder att för att säkerställa riktigheten av PDPR-förhållandet när som helst är det nödvändigt att införa följande begränsning:

Om en tupler (P1, D1 , Pp2), (P2, D1 , Pp1) och (P1, D2 , Pp1) tillhöra attityd PDPR, sedan och kortege (P1, D1 , Pp1) också tillhör detta attityd.

Om detta uttalande alltid är sant, det vill säga för alla möjliga ytterligare tupler i relationen PDPr, kommer en tidsoberoende begränsning för denna relation att erhållas, som kallas en 3D-begränsning. Eftersom en 3D-begränsning är uppfylld när relationen är likvärdigt med att ansluta några av dess projektioner, kallas denna begränsning ett anslutningsberoende.

Du kan uppmärksamma det faktum att det i exemplet vi överväger finns en viss cykliskitet i uppgifterna. Kriteriet för n-sönderdelning av en relation för n\u003e 2 är en viss cyklisk begränsning. Vad betyder cyklisk begränsning? I vårt exempel, låt den sista tupeln innebära att Smith levererar skiftnycklar till Manhattan-projektet. De tre första tupporna har information om att Smith levererar skiftnycklar, Smith är leverantör för Manhattan-projektet och skiftnycklar används för Manhattan-projektet. Men det följer inte av dessa uttalanden att det är Smith som levererar nycklarna för detta projekt. Om vi \u200b\u200bsönderdelar relationen PDPr, bestående av dessa tre tuplar, i tre projektioner, kommer deras anslutning inte att vara lika med den ursprungliga - en "extra" fjärde tupel kommer att visas (P1, D1, Pr1), som nämnts ovan. För att undvika en sådan skillnad införs en ytterligare begränsning, som lätt kan implementeras genom sönderdelning av förhållandet. Sådan sönderdelning är möjlig utan förlust av information endast om det finns ett samband beroende:

Attityd R (X, Y,. , Z) uppfyller beroenden anslutningar * (X, Y,. , Z) i tom och endast i tom fall, när R återhämtar utan förluster förbi anslutningar deras utsprång på X, Y,. , Z.

Tänk på två exempel på avvikelser som finns i en relation som har en 3D-begränsning.

2. I relationen som visas i fig 15 kan tupeln (P2, D1, Pr1) raderas utan problem. Men om du tar bort (P1, D1, Pr1), måste du ta bort en av de återstående, så att det inte finns någon cykliskitet i data.

Nu kan Feigin's teorem formuleras enligt följande:

Attityd R (OCH, FÖRE KRISTUS) uppfyller beroenden anslutningar * (AB, OCHFRÅN) sedan och endast sedan, när den uppfyller tvetydig beroenden OCH I och OCH FRÅN.

Anslutningsberoende är en generalisering av begreppet multivaluedberoende. Dessutom är det den vanligaste beroendeformen.

Återvända till relationen Leverantörer-detaljer-projekt, kan du upptäcka att det innehåller ett anslutningsberoende DAP * (D, D, D), som varken är funktionellt eller flervärdat beroende och inte antyds av dess enda potentiella nyckel - en kombination av alla attribut. Det rekommenderas att sönderdela en sådan relation i de projektioner som anges av anslutningsberoendet. Denna nedbrytningsprocess kan upprepas tills alla resulterande förhållanden är i femte vanligt form (5NF).

Attityd R belägen i femte vanligt form i tom och endast i tom fall, när några beroende anslutningar i R skall av existens några möjlig nyckel i R.

En mindre strikt definition av 5NF:

Tabell belägen i femte vanligt form (5NF) sedan och endast sedan, när i varje henne komplett sönderfall allt utsprång innehålla möjlig nyckel. Tabell, inte har inte heller ett komplett sönderfall, också belägen i 5NF.

Nu kan vi säga att efter 3-sönderdelningen av förhållandet mellan PDPr är dess prognoser PD, DPr och PPr i 5 normal form, eftersom det för dem inte finns något kopplingsberoende alls.

Den fjärde normala formen (4NF) är ett speciellt fall av 5NF, när den fullständiga nedbrytningen måste vara en sammansättning av exakt två projektioner. Det är inte lätt att hitta en riktig tabell som skulle vara i 4NF, men inte skulle vara i 5NF.

För en given relation R kan man hävda att den är i 5NF, förutsatt att alla potentiella nycklar och alla anslutningsberoenden är kända. Det finns dock ingen algoritm för att bestämma alla anslutningsberoenden. Men sådana förhållanden är extremt sällsynta i praktiken.

Den femte normala formen är den sista normala formen som kan erhållas genom sönderdelning. Förhållandena är ganska icke-triviala, men det används praktiskt taget inte.

Normalisering och konstruktionsförfarande

Vi tittade på den förlustfria sönderdelningstekniken som används för databasdesign. Huvudtanken med denna teknik är att systematiskt minska det ursprungliga förhållandet i 1NF till en uppsättning mindre förhållanden, som i en viss mening motsvarar det ursprungliga förhållandet, men mer föredraget. Varje steg i reduktionsprocessen består av att dela upp relationerna som erhållits i föregående steg i prognoser. I detta fall används de angivna begränsningarna i varje steg i normaliseringsproceduren för att välja projektioner vid nästa steg. Normalisering är att dela upp en relation (tabell) i flera relationer som har bättre egenskaper vid uppdatering, inklusive och radering av data. Denna process för att sekvensiellt ersätta en tabell med dess fullständiga sönderdelning utförs tills alla är i 5NF (i praktiken är de vanligtvis begränsade till att minska förhållandet till Boyes-Codd-normalform). I allmänhet kan följande mål för normaliseringsprocessen särskiljas:

eliminering av vissa typer av redundans;

eliminering av vissa avvikelser vid uppdatering, inkludering och borttagning;

utforma en databaslayout som är en "bra" representation av den verkliga världen, är intuitiv och ger en bra grund för vidare utveckling;

förenkla processen för att införa integritetsbegränsningar.

Låt oss lista de grundläggande reglerna som används i normaliseringsförfarandet.

1. Det enhetliga förhållandet måste reduceras till 1NF.

2. Relationer i 1NF bör delas upp i prognoser för att utesluta alla funktionella beroenden som inte är oåterkalleliga.

Med andra ord, om en relation har en sammansatt primär nyckel av formen (K1, K2) och även innehåller ett fält F, som funktionellt beror på en del av denna nyckel, till exempel på K2, men inte på den fullständiga nyckeln, rekommenderas i detta fall att bilda en annan relation som innehåller K2 och F (primär nyckel - K2) och ta bort F från det ursprungliga förhållandet:

Som ett resultat av denna åtgärd kommer en uppsättning relationer i 2NF att erhållas.

3. Relationer i 2NF bör delas upp i prognoser för att utesluta eventuella transitive funktionella beroenden. Med andra ord, om en relation har en potentiell nyckel K, ett attribut F1 som inte är en potentiell nyckel, som funktionellt beror på K, och ett annat icke-nyckelattribut F2 som funktionellt beror på F1, rekommenderas det att ta bort F2-attributet från den ursprungliga relationen och bilda en annan relation som innehåller F1 och F2, med den primära nyckeln F1.

Resultatet blir en uppsättning relationer i 3NF.

5. Relationerna i NFBC bör delas upp i prognoser för att utesluta alla flervärda beroenden som inte är funktionella beroenden. Som ett resultat kommer en uppsättning relationer i 4NF att erhållas (i praktiken utesluts vanligtvis sådana flervärda beroenden när man skapar de initiala relationerna, separerar oberoende upprepade grupper).

6. Förhållanden bör delas upp i prognoser för att eliminera eventuella sammankopplingsberoenden som inte antyds av potentiella nycklar om de kan identifieras. Således kommer en uppsättning av relationer i 5NF att erhållas (fullständig nedbrytning av relationer).

När man följer de föreslagna reglerna måste man komma ihåg att uppdelning i projektioner bör utföras utan dataförlust och med bevarande av funktionella och flervärda beroenden.

De rekommenderade rekommendationerna för normalisering är bara riktlinjer och det kan finnas situationer där normalisering inte bör utföras från början till slut. Det finns flera skäl för detta antagande. För det första kan normalisering hjälpa till att få vissa integritetsbegränsningar i en enkel form, men förutom funktionella och flervärda beroenden och koppla beroenden kan andra typer av beroenden existera i praktiken. För det andra finns det få kriterier för att välja den föredragna sönderdelningen. För det tredje är processen för normalisering och bevarande av beroende inte alltid kompatibel. För det fjärde kan inte all redundans elimineras i normaliseringsprocessen.

Databasesystemdesign börjar med att bygga en infologisk datamodell, d.v.s. identifiering av enheter. Sedan måste följande steg i konstruktionsförfarandet följas:

1. Presentera varje oberoende enhet med en databastabell (bastabell) och definiera den primära nyckeln för denna bastabell.

2. Presentera varje förening (relation mellan enheter) som en bastabell. Använd utländska nycklar i denna tabell för att identifiera medlemmar i föreningen och specificera de begränsningar som är associerade med var och en av dessa utländska nycklar.

3. Presentera egenskaper hos enheter som bastabeller med en utländsk nyckel som identifierar motsvarande enheter. Ange begränsningar för de utländska nycklarna i dessa tabeller och deras primära nycklar.

4. För att utesluta oavsiktliga kränkningar av eventuella normaliseringsprinciper i projektet, utför normaliseringsförfarandet.

5. Om tabellerna delades upp i normaliseringsprocessen, bör den infologiska modellen för databasen ändras och stegen som listas bör upprepas.

6. Ange integritetsbegränsningarna för den designade databasen och ge (om nödvändigt) en kort beskrivning av de resulterande tabellerna och deras fält.

För en visuell representation av strukturen i systemet som designas kan språket för infologisk modellering "Table-Link" användas, som används i de vanligaste relationella databaserna. I den representeras alla enheter som tabeller med en kolumn med titlar som består av enhetsnamnet. Tabellrader är en lista med entitetsattribut och de som utgör den primära nyckeln markeras. Relationer mellan enheter indikeras med pilar som pekar bort från primära nycklar eller deras beståndsdelar.

7. Ett exempel på databasdesign

Syfte och ämnesområde

Databasen är utformad för att lagra information om personalen i ett visst företag. Företaget har flera avdelningar. Varje avdelning har flera anställda, flera projekt och flera kontor. Varje anställd har flera uppgifter. För varje uppgift finns ett ark med en lista över de belopp som den anställde har fått för utförandet av detta arbete. Varje kontor har flera telefoner.

Följande information ska lagras i databasen:

För varje avdelning: unikt avdelningsnummer, budget och unikt avdelningschefnummer;

för varje anställd: ett unikt anställdnummer, aktuellt projektnummer, kontonummer, telefonnummer samt namnet på det utförda arbetet tillsammans med datum och belopp för alla betalningar som erhållits för utförandet av detta arbete;

för varje projekt: unikt projektnummer och budget;

för varje kontor: ett unikt kontornummer, område, alla telefonnummer.

Semantiska uttalanden (begränsningar): Ingen anställd är samtidigt chef för flera avdelningar; ingen anställd arbetar samtidigt på mer än en avdelning; ingen anställd arbetar samtidigt med mer än ett projekt; ingen anställd har mer än ett kontor åt gången; ingen anställd har mer än en telefon åt gången; ingen anställd har mer än ett jobb samtidigt; inget projekt ges samtidigt till mer än en avdelning; inget kontor tillhör mer än en avdelning samtidigt.

Databasdesign

Analys av ovan definierade objekt och attribut tillåter dig att markera enheterna i den designade databasen och bygga dess infologiska modell i form av "Tabeller-länkar" (Fig. 16).

Fikon. 16. Information om företaget som ska lagras i databasen

Den ursprungliga hierarkiska strukturen kan ses som ett onormaliserat förhållande:

AVDELNINGAR (AVDELNING NR., BUDGET_O, MANUELLT NR., MEDARBETARE, PROJEKT, KONTOR) KANDIDATSKNAPP (AVDELNING NR.) KANDIDATSKNAPP (MANUELLT NUMMER)

Här är betydelsen av attributen OTD # (unikt avdelningsnummer), BUDGET_O, RUK # (chefens nummer) tydliga från namnen, och attributen MEDARBETARE, PROJEKTER, KONTOR består av värdesrelationer. Vi kan beskriva deras kapslade attribut:

AVDELNINGAR (DEPARTMENT #, BUDGET, MANAGEMENT #, MEDARBETARE (SOTR #, PROJECT #, KAB #, TEL #, ARBETE (TEMA, BETALNING (DATUM, BOND))), PROJEKT (PROJEKT #, BUDGET_P), KONTOR (KAB #, OMRÅDE, TELEFON (TEL #))) KANDIDATKNAPP (AVDELNING #) KANDIDATKNAPP (MAN #)

Nu kan vi föra denna attityd till uppsättningen av relationer i 1NF. Samtidigt, med tanke på varje värdeförhållande separat, utesluter vi alla multivaluerade beroenden som inte är funktionella beroenden.

AVDELNINGAR1 (AVDELNING #, BUDGET_O, HAND #) PRIMÄRKNAPP (AVDELNING #) VÄXLIGT NYCKEL

MEDARBETARE 1 (SOTR #, DEP #, PROJECT #, CAB #, TEL #) PRIMARY KEY (SOTR #)

ARBETE1 (ÄMNE, SOTR #) PRIMÄRKNAPP (ÄMNE, SOTR #)

BETALNING1 (SOTR #, ÄMNE, DATUM, BEDRAG) PRIMÄRKNAPP (SOTR #, SUBJECT, DATE)

PROJECTS1 (PROJECT #, BUDGET_P, DEP #) PRIMARY KEY (PROJECT #)

HÅLLOR1 (HÅLLNY., KVARTAL, AVDELNING NR.) PRIMÄRKNAPP (CABIN NR.)

TELEFONER1 (TEL #, CAB #) PRIMÄRKNAPP (TEL #)

Relationerna AVDELNINGAR1, MEDARBETARE1, BETALNING1, PROJEKTER1, KONTOR1 och PHONES1 finns redan i 2NF.

Relation WORK1 är en projicering av relationen BETALNING1, därför innehåller den överflödiga information och kan raderas utan dataförlust. Samtidigt är PHONES1-förhållandet en projicering av EMPLOYEE1-förhållandet, men när det raderas kommer uppdateringsavvikelser att visas - data på telefoner kommer inte att existera utan data om specifika anställda.

Låt oss nu visa strukturen i databasen, vars förbindelser reduceras till 2NF, med hjälp av modelleringsspråket "Table-Link", som används i MS ACCESS DBMS:

Vidare, exklusive transitive beroende, kan relationer reduceras till en motsvarande uppsättning av relationer i 3NF. Den enda relationen, som inte finns i 3NF, är SAMARBETE-förhållandet, där attributen KAB # och OTD # tillfälligt beror på den primära nyckeln SOTR # - KAB # till TEL #, och OTD # till och med PROJECT # och dessutom genom KAB # och TEL #. Då kan EFFICIENCY-förhållandet ersättas av en uppsättning projektioner som finns i 3NF:

X (TEL #, KAB #) PRIMÄRKNAPP (TEL #)

Y (PROJECT #, DEP #) PRIMÄRKNAPP (PROJECT #)

Z (KAB #, DTD #) PRIMÄRKNAPP (KAB #)

Men relationen X är en analog till relationen PHONE2, Y är projektionen för relationen PROJECT2, Z är projektionen för OFFICE2 och kan därför tas bort från databasmodellen. Därför ser databasmodellen, vars förhållande reduceras till 3NF, så här ut:

AVDELNINGAR3 (AVDELNING #, BUDGET_O, HAND #) PRIMÄRKNAPP (AVDELNING #) VÄXLIGT NYCKEL (HAND #)

SOTRUDN3 (SOTR #, PROJECT #, TEL #) PRIMÄRKNAPP (SOTR #)

BETALNING3 (SOTR #, ÄMNE, DATUM, BEDRAG) PRIMÄRKNAPP (SOTR #, SUBJECT, DATE)

PROJECTS3 (PROJECT #, BUDGET_P, DEP #) PRIMARY KEY (PROJECT #)

KABINETTER 3 (KABINETTER, OMRÅDE, AVDELNING NR.) PRIMÄRKNYGL (KABINER)

TELEFON3 (TEL #, CAB #) PRIMÄRKNAPP (TEL #)

Var och en av dessa relationer finns i NFBC. Dessutom finns de i 4NF - vi fick bort eventuella flervärde beroenden i skedet av att föra modellen till 1NF. Alla relationer innehåller inte synliga avvikelser och det kan därför antas att databasen är korrekt utformad.

Litteratur

1. Beck, Kent Enterprise Implementeringsmönster; M .: Williams, 2008 .-- 369 s.

2. Weimayer, R .; Sotel, R. Master Microsoft SQL Server 2000 på egen hand på 21 dagar (+ CD-ROM); M .: Williams, 2013 .-- 549 s.

3. Ganderloi, Mike; Harkins, Susan Sales Automatiserar Microsoft Access med VBA; M .: Williams, 2013 .-- 416 s.

4. Getz, Ken; Ginbert, Michael; Litvin, Paul Access 2000. En utvecklarhandbok. Volym 1. Skrivbordsapplikationer. volym 1; Kiev: BHV, 2008 .-- 576 s.

5. Golitsyna, O. L. Databaser; Forum; Infra-M, 2013 .-- 399 sid.

6. Grinchenko, N.N. och andra. Designa databaser. Microsoft Access DBMS; Hotline Telecom, 2012. - 613 s.

7. Date, CJ. Introduktion till databassystem; K .: Dialektik; Utgåva 6, 2012 .-- 360 sid.

8. Davidson, Louis databasdesign med SQL Server 2000; Binom, 2009 .-- 631 s.

9. Duval, Paul M. Kontinuerlig integration. Förbättra programvarukvaliteten och minska risken; M .: Williams, 2008 .-- 497 s.

10. Karatygin, S .; Tikhonov, A. Arbetar i paradox för Windows 5.0 med exempel; M .: Binom, 2011 .-- 512 sid.

11. Karatygin, Sergey Access 2000 med exempel. Användarmanual med exempel; M .: Laboratory of Basic Knowledge, 2012 .-- 376 s.

12. Kaufeld, John Microsoft Office Access 2003 för Dummies; M .: Dialektika, 2013 .-- 439 s.

13. Couchman, Jason; Schwinn, Ulrike Oracle 8i CertifiedProfessionaql DBA-utbildning för databasadministratörer; LORI, 2009 .-- 510 s.

Liknande dokument

Databas systemkoncept. Den relationella modellen och dess egenskaper. Integritet i den relationella modellen. Relationsalgebra. Problem med databasdesign. Normala former av relationer. Databasdesign med metoden för enhetsförhållande. ER-diagram. SQL-språk.

en kurs med föreläsningar tillagda 10/03/2008


Med normalisering. Andra och tredje normala former. Boyes-Codd normal form. Fjärde och femte normala former. Semantisk datamodellering, ER-diagram. Grundläggande begrepp i modellen Enhet-relation.

test, tillagd 08/07/2007


Konceptet att normalisera databastabeller och dess syfte. Stadier av normaliseringsprocessen. Ett exempel på onormal information. Normala former till vilka tabeller reduceras. Relationsalgebra över träningsbasen. Databas för ämnesområdet "Tutorials".

test, tillagd 30-30/2010


Skapa en databasstruktur på exemplet "Skolatidskrift" med hjälp av metod och princip för normalisering. Databaskoncept, databasarkitektur och design. Beskrivning av ämnesområdet; applikationer för att arbeta med TTable- och TQuery-databasen.

avhandling, tillagd 04/01/2012


Studie av de teoretiska grunderna för databasdesign och utveckling. Att avslöja funktionella beroenden, bygga en infologisk modell. En översikt över språket och programvaran för att skapa, underhålla och dela databaser.

terminer, tillagd 02/22/2012


Auktorisation med kataloger för design av butiksdatabaser. Databasuppgifter: redovisning av alla varor, sökning och leverans av kunddata, adress, telefonnummer, pris och tillgänglighet av varor. Databasdesignstadier. Dataschema, skapande av förfrågningar och deras former.

abstrakt, tillagd 10/22/2009


Grunderna i relation till databasdesign. Ett diagram över förhållandet mellan modeller och representationer av ett komplext system i processen med objektorienterad analys. Exempel på grafiska representationer av specifika klasser. Förstå informationsdatamodellen.

presentation tillagd 14/10/2013


Definitioner som krävs för att förstå normaliseringsbaserad design av relationella databaser. Förlustfri nedbrytning av Heaths sats. Onormala uppdateringar. Utveckling av databasmodeller och applikationer, analys av problem under skapandet.

presentation tillagd 14/10/2013


Integrerad databas. Utveckling av konceptet och strukturen för en företagsdatabas för ett nytt informationssystem. Metoder i databasdesignmetoder: komponentöppenhet och semantisk interoperabilitet; utveckling av konceptuella modeller.

rapporten lades till 01/11/2011


Analys av ämnesområdet, dess formalisering med funktionella beroenden. Steg för att minimera systemet med funktionella beroenden och, baserat på det resulterande reducerade systemet, utforma en databasmodell. Skapa och modellera frågor.

Att designa databaser över informationssystem är en ganska besvärlig uppgift. Det utförs på grundval av att formalisera strukturen och processerna inom ämnesområdet, information om vad som ska lagras i databasen. Skilja på konceptuelloch schematiskstrukturelldesign.

Begreppsdesign av en IS-DB är till stor del en eurhistorisk process. Tillgången för den infologiska modellen för ämnesområdet som byggs inom dess ramverk bekräftas empiriskt i processen för IS-funktion.

Låt oss lista stadierna i konceptuell design:

* studie av ämnesområdet för att skapa en allmän uppfattning om det;

* urval och analys av funktioner och uppgifter för det utvecklade IS;

* definition av huvudobjektenheter i ämnesområdet och förhållandet mellan dem;

* formaliserad presentation av ämnesområdet.

Vid utformning av ett relationsdatabasschema kan följande procedurer särskiljas:

* bestämning av listan över tabeller och länkar mellan dem;

* bestämning av listan över fält, fälttyper, nyckelfält i varje tabell (tabellschema), upprättande av länkar mellan tabeller genom utländska nycklar;

* upprättande av indexering för fält i tabeller;

* utveckling av listor (ordböcker) för fält med uppräknade data;

* ställa integritetsbegränsningar för tabeller och länkar;

* normalisering av tabeller, korrigering av tabellen och länkar. Databasdesign utförs på fysiska och logiska nivåer. Design på fysisk nivå utförs med hjälp av ett DBMS och är ofta automatiserat.

Logisk design består i att bestämma antalet och strukturen på tabeller, utveckla frågor till databasen, rapportera dokument, skapa formulär för att mata in och redigera data i databasen etc.

En av de viktigaste uppgifterna för logisk databasdesign är datastrukturering. Följande metoder för utformning av datastrukturer skiljer sig:

* att kombinera information om entitetsobjekt inom en tabell (en relation) med efterföljande sönderdelning i flera sammankopplade tabeller baserat på normalisering av relationer;

* formulering av kunskap om systemet (bestämning av typen av initiala data och relationer) och krav för databehandling, erhållande av ett färdigt databasschema eller till och med ett färdigt applikationsinformationssystem med CA5E-systemet;

* Implementering av systemanalys och utveckling av strukturella

Informationssystem

Mänskligheten i dag upplever en informationsexplosion. Volymen av information som kommer till en person genom alla informationsmedier växer ständigt. För varje person som bor i informationssamhället är det därför mycket viktigt att behärska medlen för optimal lösning på problemet med ansamling, beställning och rationell användning av information.

Mänsklig förmåga att bearbeta information har ökat dramatiskt med användning av datorer. Vid användning av datorer för att lösa informationstjänstproblem kan två perioder skiljas:

 den inledande perioden, då en liten cirkel av människor - systemprogrammerare - var involverade i att lösa informationsbehandlingsproblem, organisera data. Denna period kännetecknas av det faktum att programvaruverktyg skapades för att lösa ett specifikt databehandlingsproblem. Samtidigt, för att lösa ett annat problem där samma data användes, var det nödvändigt att skapa nya program;

 period för systematisk datoranvändning. För att lösa ett komplex av uppgifter på en dator skapas programverktyg som fungerar med samma data och använder en enda informationsmodell för objektet. Dessa verktyg beror inte på objektets art, dess modell, de kan användas för informationstjänster för olika uppgifter. Mänskligheten har kommit till organisationen av information i informationssystem.

Informationssystem (IS) är stora mängder data tillsammans med programvara och hårdvara för deras bearbetning. Det finns följande typer av IP: faktiska, dokumentära och expertsystem.

Faktografisk IP är en mängd fakta - specifika datavärden om objekt i den verkliga världen.

Informationen i det faktiska IS lagras i en tydligt strukturerad form, så den kan ge entydiga svar på de frågor som ställs, till exempel: "Vem är vinnaren av det ryska gymnastikmästerskapet 1999?", "Vem äger en AUDI 80-bil med registreringsnummer PA899P77?" "Vad är telefonnumret i redovisningsavdelningen vid Moskva statsuniversitet?", "Vem blev Rysslands president vid valet i mars 2002?" etc. Faktografiska IC: er används bokstavligen inom alla områden av mänsklig aktivitet - inom vetenskap, materialproduktion, transport, medicin, myndigheter och offentliga liv, handel, kriminalteknik, konst, sport.

Dokumentära informationssystem tjäna en grundläggande annan klass av problem som inte innebär ett entydigt svar på den ställda frågan. Databasen för sådana system bildas av en uppsättning ostrukturerade textdokument (artiklar, böcker, abstrakta, lagtexter) och grafiska objekt, utrustade med en eller annan formaliserad sökanordning. Syftet med systemet är som regel att returnera, som svar på en användares begäran, en lista över dokument eller objekt som till viss del uppfyller villkoren formulerade i begäran. Till exempel: lista alla artiklar som innehåller ordet "Pushkin". En grundläggande funktion i det dokumentära systemet är dess förmåga, å ena sidan, att utfärda dokument som är onödiga för användaren (till exempel där ordet "Pushkin" används i en annan mening än avsedd), och å andra sidan att inte utfärda nödvändiga dokument (till exempel om författaren använde någon synonym) eller felstavat). Dokumentarsystemet bör kunna bestämma betydelsen av en viss term genom sammanhang, till exempel att skilja mellan "kamomill" (växt), "kamomill" (typ av skrivhuvud för en skrivare).

Expert-system (ES) - intelligenta system utformade för att spela rollen som "rådgivare" är byggda på basis av formaliserad erfarenhet och expertkunskap. Kärnan i ES är kunskapsbaser som samlar in kunskap från experter (specialister) inom ett visst område, på grundval av vilket ES tillåter dig att modellera resonemanget för specialister från ett visst ämnesområde.

Den specificerade klassificeringen och tillskrivningen av IS till en eller annan typ är föråldrad, eftersom moderna faktiska system ofta arbetar med ostrukturerade informationsblock (text, grafik, ljud, video), försedda med strukturerade deskriptorer.