Begreppet relationellt är förknippat med utvecklingen av en berömd amerikansk specialist inom området databassystem, en anställd hos IBM, Dr. E. Codd (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6 , juni 1970), som först använde termen "relationell datamodell".

Under lång tid ansågs det relationella tillvägagångssättet som en bekväm formell apparat för databasanalys, som inte hade några praktiska utsikter, eftersom implementeringen krävde för många maskinresurser. Först med intåget av persondatorer började relations- och relaterade system spridas och lämnade praktiskt taget inget utrymme för andra modeller.

Dessa modeller kännetecknas av enkel datastruktur, användarvänlig tabellrepresentation och förmågan att använda den formella apparaten för relationalgebra och relationskalkyl för databehandling.

Relationsmodellen fokuserar på att organisera data i form av tvådimensionella tabeller. Varje relationstabell är en tvådimensionell array och har följande egenskaper:

• - varje tabellelement är ett dataelement; det finns inga återkommande grupper;
• - alla kolumner i tabellen är homogena, dvs. alla element i en kolumn har samma typ (numerisk, tecken, etc.) och längd;
• - varje kolumn har ett unikt namn;
• - det finns inga identiska rader i tabellen;
• - ordningen på rader och kolumner kan vara godtycklig. Denna typ av tabell kallas en relation.

En databas byggd med hjälp av relationer kallas en relationsdatabas.

Relationer presenteras i form av tabeller, vars rader motsvarar tupler eller poster, och kolumnerna motsvarar relationsattribut, domäner och fält.

Ett fält, vars varje värde unikt identifierar motsvarande post, kallas en enkel nyckel (nyckelfält). Om poster unikt identifieras av värden i flera fält, har en sådan databastabell en sammansatt nyckel.

För att länka två relationstabeller måste du inkludera nyckeln till den första tabellen som en del av nyckeln till den andra tabellen (nycklarna kan sammanfalla); annars måste du ange en främmande nyckel i strukturen för den första tabellen - nyckeln för den andra tabellen.

Efter att ha föreslagit en relationsdatamodell har E.F. Codd skapade också ett verktyg för bekvämt arbete med relationer – relationalgebra. Varje operation av denna algebra använder en eller flera tabeller (relationer) som sina operander och producerar en ny tabell som ett resultat, dvs. låter dig "klippa" eller "limma" tabeller.

Hur relationsmodeller i grunden skiljer sig från nätverk och hierarkiska kan sägas på följande sätt: hierarkiska och nätverksdatamodeller är sammankopplade genom struktur, och relationella är sammankopplade genom mening.

Databasdesign har traditionellt sett ansetts vara en mycket svår uppgift. Relationsteknik gör denna uppgift mycket enklare.

Genom att separera de logiska och fysiska skikten i ett system förenklar det processen att kartlägga det "verkliga världens skikt" till en struktur som systemet direkt kan stödja. Eftersom själva relationsstrukturen är begreppsmässigt enkel tillåter den implementering av små och/eller enkla (och därför lätta att skapa) databaser, såsom personliga databaser, som aldrig skulle ha ansetts möjliga i äldre, mer komplexa system.

Teorin och disciplinen för normalisering kan hjälpa till genom att visa vad som händer när relationer inte är naturligt strukturerade.

Den relationella datamodellen är särskilt bekväm att använda i distribuerade arkitekturdatabaser - den låter dig komma åt alla informationselement som lagras i datornätverksnoder. Det är nödvändigt att ägna särskild uppmärksamhet åt högnivåaspekten av det relationella tillvägagångssättet, som består av multipel registreringsbearbetning. Tack vare detta ökar potentialen i det relationella tillvägagångssättet avsevärt, vilket inte kan uppnås vid bearbetning av en post i taget och framför allt handlar det om optimering.

Denna modell låter dig bestämma:

• · operationer för att lagra och hämta data;
• · begränsningar för att säkerställa dataintegritet.

För att öka operativ effektivitet antar många relationella DBMS begränsningar som motsvarar en strikt relationsmodell.

Många relationella DBMS presenterar databasfiler för användaren i ett tabellformat - med poster som rader och deras fält som kolumner. I tabellform uppfattas information mycket lättare. Men i en databas på fysisk nivå lagras data vanligtvis i filer som innehåller sekvenser av poster.

Den största fördelen med relations-DBMS är möjligheten att länka databasfiler baserat på vissa relationer.

Ur en strukturell synvinkel är relationsmodeller enklare och mer homogena än hierarkiska och nätverksmodeller. I relationsmodellen har varje domänobjekt en eller flera relationer. Om det är nödvändigt att uttryckligen definiera förhållandet mellan objekt, uttrycks det i form av en relation där identifierare för inbördes relaterade objekt finns som attribut. I den relationella modellen representeras ämnesområdets objekt och kopplingarna mellan dem av samma informationsstrukturer, vilket avsevärt förenklar själva modellen.

En DBMS anses vara relationell om följande två villkor, föreslagna av E. Codd, är uppfyllda:

• · stöder relationsdatastruktur;
• · implementerar åtminstone operationerna för urval, projektion och koppling av relationer.

Därefter skapades ett antal relationella DBMS som mer eller mindre uppfyller denna definition. Många DBMS är betydande förlängningar av relationsmodellen, medan andra är blandade och stöder flera datamodeller.

Idag är relationsdatabaser fortfarande de vanligaste på grund av sin enkelhet och tydlighet, både under skapandet och på användarnivå.

Den största fördelen med relationsdatabaser är deras kompatibilitet med det mest populära frågespråket, SQL.

Med en enda fråga på det här språket kan du sammanfoga flera tabeller till en temporär tabell och klippa ut de rader och kolumner som krävs från den (urval och projektion). Eftersom tabellstrukturen för en relationsdatabas är intuitiv för användare, är SQL-språket enkelt och lätt att lära sig. Relationsmodellen har en solid teoretisk grund på vilken utvecklingen och implementeringen av relationsdatabaser baserades. Som följd av den våg av popularitet som genererades av framgången med relationsmodellen blev SQL det primära språket för relationsdatabaser.

Men nackdelarna med den övervägda databasmodellen har också identifierats:

• - eftersom alla fält i en tabell måste innehålla ett konstant antal fält av fördefinierade typer, är det nödvändigt att skapa ytterligare tabeller som tar hänsyn till de individuella egenskaperna hos elementen med hjälp av främmande nycklar. Detta tillvägagångssätt gör det mycket svårt att skapa några komplexa relationer i databasen;
• - hög komplexitet att manipulera information och ändra kopplingar.

Framväxten av datorteknik i vår moderna tid har markerat en informationsrevolution inom alla områden av mänsklig verksamhet. Men för att förhindra att all information blir onödigt skräp på det globala Internet uppfanns ett databassystem där material sorteras, systematiseras, vilket gör det lätt att hitta och lämna in för efterföljande bearbetning. Det finns tre huvudtyper - relationella, hierarkiska och nätverksdatabaser.

Grundläggande modeller

För att återgå till uppkomsten av databaser är det värt att säga att denna process var ganska komplex, den har sitt ursprung i utvecklingen av programmerbarg. Därför är det inte förvånande att antalet modeller för närvarande når mer än 50, men de viktigaste är hierarkiska, relationella och nätverk, som fortfarande används i stor utsträckning i praktiken. Vad är dem?

Hierarchical har en trädstruktur och är uppbyggd av data från olika nivåer, mellan vilka det finns kopplingar. Nätverksdatabasmodellen är ett mer komplext mönster. Dess struktur liknar en hierarkisk, och dess schema utökas och förbättras. Skillnaden mellan dem är att en hierarkisk modells efterkommande data bara kan ha en koppling till en förfader, medan en nätverksmodell kan ha flera av dem. Strukturen för en relationsdatabas är mycket mer komplex. Därför bör det analyseras mer i detalj.

Grundkonceptet för en relationsdatabas

Denna modell utvecklades på 1970-talet av Dr. Edgar Codd. Det är en logiskt strukturerad tabell med fält som beskriver data, deras relationer med varandra, de operationer som utförs på dem, och viktigast av allt, reglerna som garanterar deras integritet. Varför kallas modellen relationell? Den bygger på relationer (från latinets relation) mellan data. Det finns många definitioner för denna typ av databas. Relationstabeller med information är mycket lättare att systematisera och bearbeta än i ett nätverk eller en hierarkisk modell. Hur gor man det har? Det räcker att känna till egenskaperna, modellens struktur och egenskaper hos relationstabeller.

Processen att modellera och sammanställa grundläggande element

För att skapa ditt eget DBMS bör du använda ett av modelleringsverktygen, fundera över vilken information du behöver arbeta med, designa tabeller och relationella enstaka och multipla relationer mellan data, fylla i entitetsceller och ställa in primära och främmande nycklar.

Tabellmodellering och relationsdatabasdesign görs med gratisverktyg som Workbench, PhpMyAdmin, Case Studio, dbForge Studio. Efter detaljerad design bör du spara den grafiskt färdiga relationsmodellen och översätta den till färdig SQL-kod. I detta skede kan du börja arbeta med datasortering, bearbetning och systematisering.

Funktioner, struktur och termer associerade med relationsmodellen

Varje källa beskriver sina beståndsdelar på sitt eget sätt, så för att minska förvirringen skulle jag vilja ge ett litet tips:

• relationstabell = enhet;
• layout = attribut = fältnamn = enhetskolumnrubriker;
• entitetsinstans = tuppel = post = tabellsträng;
• attributvärde = enhetscell = fält .

För att gå vidare till egenskaperna för en relationsdatabas bör du veta vilka grundkomponenter den består av och vad de är avsedda för.

1. Väsen. Det kan finnas en tabell i en relationsdatabas, eller så kan det finnas en hel uppsättning tabeller som kännetecknar de beskrivna objekten tack vare data som lagras i dem. De har ett fast antal fält och ett variabelt antal poster. En relationsdatabasmodelltabell består av rader, attribut och layout.
2. En post är ett variabelt antal rader som visar data som kännetecknar objektet som beskrivs. Numreringen av poster utförs automatiskt av systemet.
3. Attribut är data som beskriver en entitets kolumner.
4. Fält. Representerar en enhetskolumn. Deras nummer är ett fast värde, som ställs in när tabell skapas eller ändras.

Nu, genom att känna till de beståndsdelar i tabellen, kan du gå vidare till egenskaperna för den relationella databasmodellen:

• Relationella databasenheter är tvådimensionella. Tack vare denna egenskap är det lätt att utföra olika logiska och matematiska operationer med dem.
• Ordningen på attributvärden och poster i en relationstabell kan vara godtycklig.
• En kolumn i en relationstabell måste ha ett eget individuellt namn.
• All data i en entitetskolumn har en fast längd och samma typ.
• Varje post betraktas i huvudsak som en datapost.
• Komponenterna i strängarna är unika. Det finns inga identiska rader i en relationsenhet.

Baserat på egenskaperna är det tydligt att attributvärdena måste vara av samma typ och längd. Låt oss titta på egenskaperna hos attributvärden.

Huvudegenskaper hos relationsdatabasfält

Fältnamn måste vara unika inom en enhet. Relationella databasattribut eller fälttyper beskriver vilken kategori av data som lagras i entitetsfält. Ett relationsdatabasfält måste ha en fast storlek, mätt i tecken. Parametrarna och formatet för attributvärden bestämmer hur data i dem korrigeras. Det finns också något som en "mask" eller "inmatningsmall". Det är avsett att definiera datainmatningskonfigurationen för ett attributvärde. Ett felmeddelande måste ges om en felaktig inmatning görs i ett fält. Vissa begränsningar införs också på fältelementen - villkor för att kontrollera noggrannheten och felfriheten för datainmatning. Det finns något obligatoriskt attributvärde som definitivt måste fyllas med data. Vissa attributsträngar kan vara fyllda med NULL-värden. Tom data är tillåten i fältattribut. Liksom felmeddelandet finns det värden som fylls i automatiskt av systemet - detta är standarddata. Ett indexerat fält är utformat för att påskynda sökningen efter data.

Diagram över en tvådimensionell relationsdatabastabell

För att förstå modellen i detalj med hjälp av SQL är det bäst att titta på diagrammet med ett exempel. Vi vet redan vad en relationsdatabas är. En post i varje tabell är ett dataelement. För att förhindra dataredundans måste normaliseringsoperationer utföras.

Grundläggande regler för normalisering av en relationsenhet

1. Fältnamnsvärdet för en relationstabell måste vara unikt, unikt (första normalformen - 1NF).

2. För en tabell som redan är castad till 1NF måste namnet på en icke-identifierande kolumn vara beroende av tabellens unika identifierare (2NF).

3. För en hel tabell som redan finns i 2NF kan varje icke-identifierande fält inte vara beroende av ett element av ett annat oidentifierat värde (3NF-entitet).

Databaser: relationella relationer mellan tabeller

Det finns två huvudsakliga relationstabeller:

• "En-många". Uppstår när en nyckelpost i tabell nr 1 motsvarar flera instanser av den andra enheten. En nyckelikon i ena änden av en ritad linje indikerar att enheten är på den "ena" sidan är ofta markerad med en oändlighetssymbol.

• En "många-många"-relation bildas när en explicit logisk interaktion sker mellan flera rader i en enhet med ett antal poster i en annan tabell.
• Om en en-till-en-konkatenering sker mellan två entiteter betyder det att nyckelidentifieraren för en tabell finns i den andra enheten, då bör en av tabellerna tas bort, den är redundant. Men ibland, rent av säkerhetsskäl, separerar programmerare medvetet de två enheterna. Därför kan hypotetiskt sett en en-till-en relation existera.

Förekomsten av nycklar i en relationsdatabas

Primära och sekundära nycklar definierar potentiella databasrelationer. Relationella relationer i en datamodell kan bara ha en potentiell nyckel, och detta kommer att vara den primära nyckeln. Hur är han? En primärnyckel är en entitetskolumn eller en uppsättning attribut genom vilka data kan nås för en specifik rad. Det måste vara unikt, unikt och dess fält får inte innehålla tomma värden. Om primärnyckeln endast består av ett attribut, kallas den enkel, annars blir den en komponent.

Förutom primärnyckeln finns det även en främmande nyckel. Många människor förstår inte skillnaden mellan dem. Låt oss titta på dem mer i detalj med hjälp av ett exempel. Så det finns två tabeller: "Dean's Office" och "Students". Entiteten "Dean's Office" innehåller följande fält: "Student ID", "Fullständigt namn" och "Grupp". Tabellen "Studenter" har attributvärden som "Namn", "Grupp" och "GPA". Eftersom ett student-ID inte kan vara detsamma för flera studenter, kommer detta fält att vara den primära nyckeln. "Fullständigt namn" och "Grupp" från "Studenter"-tabellen kan vara samma för flera personer, de hänvisar till student-ID-numret från "Dean's office"-enheten, så de kan användas som en främmande nyckel.

Exempel på relationsdatabasmodell

För tydlighetens skull ger vi ett enkelt exempel på en relationsdatabasmodell som består av två entiteter. Det finns ett bord som heter "Dean's Office".

Det är nödvändigt att göra kopplingar för att skapa en fullfjädrad relationsdatabas. Posten "IN-41", som "IN-72", kan förekomma mer än en gång i skylten "Dean's Office" och i sällsynta fall kan elevernas sista, för- och patronymiska namn sammanfalla, så dessa fält kan inte göras den primära nyckeln. Låt oss visa enheten "Studenter".

Som vi kan se är fälttyperna för relationsdatabaser helt olika. Det finns både digitala och symboliska register. Därför bör du i attributinställningarna ange värdena binteger, char, vachar, date och andra. I tabellen "Dean's Office" är det enda unika värdet student-ID. Detta fält kan tas som primärnyckel. Fullständigt namn, grupp och telefonnummer från entiteten "Studenter" kan tas som en främmande nyckel som refererar till student-ID. Anslutningen har upprättats. Detta är ett exempel på en en-till-en-relationsmodell. Hypotetiskt sett är en av tabellerna överflödig, de kan enkelt kombineras till en enhet. För att förhindra att studentnummer blir allmänt kända är det fullt möjligt att ha två tabeller.

utveckla språkverktyg och mjukvarusystem som säkerställer deras höga prestanda, och skapa grunden för teorin om databasdesign. Men för massanvändare av relationella DBMS:er kan informella motsvarigheter till dessa begrepp användas framgångsrikt:

"relation" - "tabell" (ibland fil), "tuple" - "rad" (ibland rekord), "attribut" - "kolumn", "fält".

Det antas att "post" betyder "en instans av en post" och "fält" betyder "fältets namn och typ."

Relationsdatabas

En relationsdatabas är en samling relationer som innehåller all information som måste lagras i databasen. Användare kan dock uppfatta en sådan databas som en samling tabeller. Det bör noteras:

Varje tabell består av rader av samma typ och har ett unikt namn; Rader har ett fast antal fält (kolumner) och värden (flera

Samma fält och upprepande grupper är inte tillåtna). Med andra ord, vid varje bordsposition i skärningspunkten mellan en rad och en kolumn, finns det alltid exakt ett värde eller ingenting;

Raderna i en tabell måste skilja sig från varandra med minst ett enda värde, vilket gör det möjligt att unikt identifiera vilken rad som helst i en sådan tabell;

Kolumnerna i tabellen är unikt tilldelade namn, och var och en av dem innehåller homogena datavärden (datum, efternamn, heltal eller monetära belopp);

Det fullständiga informationsinnehållet i databasen representeras i form av explicita datavärden och denna representationsmetod är den enda; När man utför operationer på en tabell kan dess rader och kolumner bearbetas i valfri ordning, oavsett deras informationsinnehåll. Detta underlättas av närvaron av tabellnamn och deras kolumner, samt möjligheten att välja vilken som helst av deras rader eller valfri uppsättning rader med de angivna egenskaperna (till exempel flyg med destinationen "Paris" och ankomsttid).

upp till 12 timmar).

Relationell datamanipulation

Efter att ha föreslagit en relationsdatamodell har E.F. Codd skapade också ett verktyg för bekvämt arbete med relationer – relationalgebra. Varje operation av denna algebra använder en eller flera tabeller (relationer) som sina operander och producerar en ny tabell som ett resultat, dvs. låter dig "klippa" eller "limma" tabeller (Fig. 1.5).

Ris. 1.5. Några operationer av relationalgebra

Datamanipulationsspråk har skapats som gör det möjligt att implementera alla operationer av relationalgebra och nästan vilken kombination som helst av dem. Bland dem är de vanligaste SQL (Structured Query Language).

badrumsfrågespråk) och QBE (Quere-By-Example - queries by example). Både från-

hänvisa till språk på mycket hög nivå, med hjälp av vilka användaren specificerar vilken data som behöver erhållas utan att specificera proceduren för att erhålla den.

Med en enda fråga på något av dessa språk kan du sammanfoga flera tabeller till en tillfällig tabell och klippa ut de rader och kolumner som krävs från den (urval och projektion).

Relationell databasdesign, designmål

Endast små organisationer kan konsolidera data till en helt integrerad databas. Oftast är det praktiskt taget omöjligt att täcka och förstå alla informationskrav från organisationens anställda (dvs framtida användare av systemet). Därför innehåller informationssystem för stora organisationer flera dussin databaser, ofta fördelade på flera sammankopplade datorer av olika avdelningar. (Så i stora städer skapas inte en utan flera grönsaksbaser, belägna i olika områden.)

Individuella databaser kan kombinera all data som behövs för att lösa ett eller flera applikationsproblem, eller data relaterade till något ämnesområde (till exempel ekonomi, studenter, lärare, matlagning, etc.). Den första kallas vanligtvis applikationsdatabaser, och den andra är ämnesdatabaser (korrelerade med organisationens objekt och inte med dess informationstillämpningar). Det förra kan jämföras med logistik- eller rekreationsbaser och det senare med grönsaks- och klädbaser.

Ämnesdatabaser gör det möjligt att tillhandahålla stöd för alla nuvarande och framtida applikationer, eftersom deras uppsättning av dataelement inkluderar uppsättningar av applikationsdatabasdataelement. Som ett resultat skapades ämnesdatabaser

tillhandahålla ett ramverk för bearbetning av informella, föränderliga och okända frågor och applikationer (applikationer för vilka datakrav inte kan fastställas i förväg). En sådan flexibilitet och anpassningsförmåga gör det möjligt att skapa ganska stabila informationssystem baserade på ämnesdatabaser, d.v.s. system där de flesta ändringar kan göras utan att behöva skriva om gamla applikationer.

Genom att basera databasdesign på aktuella och förutsebara applikationer kan du avsevärt påskynda skapandet av ett högeffektivt informationssystem, d.v.s. ett system vars struktur tar hänsyn till de vanligaste vägarna för att komma åt data. Därför lockar applikationsdesign fortfarande vissa utvecklare. Men när antalet applikationer av sådana informationssystem växer, ökar antalet applikationsdatabaser snabbt, nivån på dataduplicering ökar kraftigt och kostnaderna för att underhålla dem ökar.

Således påverkar var och en av de övervägda designmetoderna designresultaten i olika riktningar. Viljan att uppnå både flexibilitet och effektivitet ledde till bildandet av en designmetodik som använder både ämnes- och tillämpningsbaserade tillvägagångssätt. I allmänhet används ämnesmetoden för att bygga den initiala informationsstrukturen, och den tillämpade metoden används för att förbättra den för att öka effektiviteten i databehandlingen.

När man utformar ett informationssystem är det nödvändigt att analysera målen för detta system och identifiera kraven för det från enskilda användare (anställda i organisationen). Datainsamling börjar med att undersöka enheterna i organisationen och de processer som använder dessa enheter. Entiteter grupperas efter "likhet" (frekvensen av deras användning för att utföra vissa åtgärder) och efter antalet associativa kopplingar mellan dem (flygplan - passagerare, lärare - disciplin, student - session, etc.). Entiteter eller grupper av enheter som har den största likheten och (eller) den högsta frekvensen av associativa anslutningar kombineras till ämnesdatabaser. (Entiteter kombineras ofta till ämnesdatabaser utan användning av formella tekniker - enligt "sunt förnuft").

Huvudmålet med databasdesign är att minska redundansen av lagrad data, och därför spara mängden minne som används, minska kostnaden för flera uppdateringsoperationer av redundanta kopior och eliminera möjligheten för inkonsekvenser på grund av lagring av information om samma objekt i olika platser. Ett så kallat "rent" databasprojekt ("Varje fakta på ett ställe") kan skapas med hjälp av relationsnormaliseringsmetoden.

Normalisering är processen att dela upp en tabell i två eller flera tabeller som har bättre egenskaper när man inkluderar, modifierar och tar bort data.

Det yttersta målet med normalisering är att få en databasdesign där varje fakta förekommer på endast ett ställe, d.v.s. redundans av information är utesluten. Detta görs inte så mycket för att spara minne som för att eliminera eventuella inkonsekvenser i den lagrade datan.

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

Varje normaliserad tabell betraktas automatiskt som en tabell i första normala formen, förkortat 1NF. Så strängt taget betyder "normaliserad" och "i 1NF" samma sak. Men i praktiken används ofta termen "normaliserad" i en snävare mening.

– ”fullständigt normaliserat”, vilket innebär att projektet inte bryter mot några normaliseringsprinciper.

Nu, förutom 1NF, är det möjligt att definiera ytterligare nivåer av normala

malization – andra normalformen (2NF), tredje normalformen

(3NF), etc. I huvudsak är en tabell i 2NF om den är i 1NF

Och uppfyller dessutom ett ytterligare villkor, vars väsen kommer att diskuteras nedan. En tabell är i 3NF om den är i 2NF och dessutom uppfyller ytterligare ett ytterligare villkor

etc.

Varje normalform är således i någon mening mer begränsad, men också mer önskvärd, än den föregående. Detta beror på att "(N+1):e normalformen" inte har några av de oattraktiva egenskaperna hos "N:te normalformen". Den allmänna innebörden av det ytterligare villkoret som åläggs den (N+1):e normalformen med avseende på den N:te normalformen är att eliminera dessa oattraktiva egenskaper.

Teorin om normalisering är baserad på närvaron av ett eller annat förhållande mellan tabellens fält. Två typer av sådana beroenden definieras: funktionella

nationellt och mångvärdigt.

Funktionellt beroende. Fält B i en tabell är funktionellt beroende av fält A i samma tabell om och endast om, vid något givet tillfälle, för vart och ett av de olika värdena i fält A, det nödvändigtvis bara finns ett av de olika värdena i fältet B. Observera att det här antas att fält A och B kan vara sammansatta.

Fullt funktionellt beroende. Fält B är i full funktion

nationellt beroende av ett sammansatt fält A, om det funktionellt beror på A och inte funktionellt beror på någon delmängd av fält A.

Flervärdigt beroende. Fält A bestämmer flervärdigt fält B för det

Relationell databas - grundläggande begrepp

Ofta, när man talar om en databas, menar de helt enkelt någon automatiserad datalagring. Denna idé är inte helt korrekt. Varför det är så kommer att visas nedan.

Faktum är att i ordets snäva mening är en databas en viss uppsättning data som är nödvändig för arbetet (uppdaterad data). Data är dock en abstraktion; ingen har någonsin sett "bara data"; de uppstår inte eller existerar inte av sig själva. Data är en reflektion av objekt i den verkliga världen. Låt till exempel du vill lagra information om delar som tas emot på lagret. Hur kommer ett verkligt objekt - en del - att visas i databasen? För att kunna svara på denna fråga måste du veta vilka funktioner eller aspekter av delen som kommer att vara relevanta och nödvändiga för jobbet. Dessa kan inkludera delens namn, vikt, mått, färg, tillverkningsdatum, material som den är tillverkad av etc. I traditionell terminologi kallas verkliga objekt, information om vilka lagras i en databas, entiteter (låt inte detta ord skrämma läsaren - detta är en allmänt accepterad term), och deras faktiska egenskaper kallas attribut.

Varje attribut för ett specifikt objekt är ett attributvärde. Således har motordelen ett viktattributvärde på 50, vilket återspeglar det faktum att denna motor väger 50 kilo.

Det skulle vara ett misstag att tro att endast fysiska objekt återspeglas i databasen. Det är kapabelt att absorbera information om abstraktioner, processer, fenomen - det vill säga om allt som en person möter i sin verksamhet. Till exempel kan du i en databas lagra information om beställningar för leverans av delar till ett lager (även om det inte är ett fysiskt objekt, utan en process). Attributen för "order"-enheten kommer att vara namnet på den del som levereras, antalet delar, namnet på leverantören, leveranstid, etc.

Objekt i den verkliga världen är kopplade till varandra genom många komplexa beroenden som måste beaktas i informationsaktiviteter. Till exempel levereras delar till lagret av deras tillverkare. Därför är det nödvändigt att inkludera attributet "tillverkarens namn" bland delattributen. Detta är dock inte tillräckligt, eftersom ytterligare information om tillverkaren av en viss del kan behövas - hans adress, telefonnummer etc. Det innebär att databasen inte bara ska innehålla information om delar och inköpsorder, utan även information om deras tillverkare. Dessutom måste databasen återspegla relationerna mellan delar och tillverkare (varje del tillverkas av en specifik tillverkare) och mellan beställningar och delar (varje beställning utfärdas för en specifik del). Observera att endast relevanta, betydande anslutningar behöver lagras i databasen.

Således, i ordets breda bemärkelse, är en databas en uppsättning beskrivningar av verkliga objekt och kopplingar mellan dem som är relevanta för ett specifikt tillämpningsområde. I det följande kommer vi att utgå från denna definition och förtydliga den allt eftersom.

Relationsdatamodell

Så nu har vi en uppfattning om vad som lagras i databasen. Nu måste vi förstå hur entiteter, attribut och relationer mappas till datastrukturer. Detta bestäms av datamodellen.

Traditionellt klassificeras alla DBMS beroende på vilken datamodell som ligger till grund för dem. Det är brukligt att skilja mellan hierarkiska, nätverks- och relationsdatamodeller. Ibland kompletteras de med en datamodell baserad på inverterade listor. Följaktligen talar de om hierarkisk, nätverk, relationell DBMS eller DBMS baserat på inverterade listor.

När det gäller prevalens och popularitet är relationella DBMS idag oöverträffade. De har blivit en de facto industriell standard, och därför kommer den inhemska användaren att behöva hantera ett relationellt DBMS i sin praktik. Låt oss kort titta på den relationella datamodellen utan att fördjupa oss i dess detaljer.

Den utvecklades av Codd redan 1969-70 på basis av den matematiska relationsteorin och bygger på ett system av begrepp, varav de viktigaste är tabell, relation, rad, kolumn, primärnyckel, främmande nyckel.

En relationsdatabas är en där all data presenteras för användaren i form av rektangulära tabeller med datavärden, och alla operationer på databasen reduceras till manipulationer med tabeller. En tabell består av rader och kolumner och har ett namn som är unikt i databasen. Tabellen återspeglar typen av verkliga objekt (entitet), och var och en av dess rader representerar ett specifikt objekt. Således innehåller deltabellen information om alla delar lagrade i lagret, och dess rader är uppsättningar av attributvärden för specifika delar. Varje tabellkolumn är en samling värden för ett specifikt attribut för ett objekt. Således representerar materialkolumnen en uppsättning värden "Stål", "Tin", "Zink", "Nickel" etc. Kolumnen Kvantitet innehåller icke-negativa heltal. Värdena i Vikt-kolumnen är reella tal lika med vikten av delen i kilogram.

Dessa värden visas inte ur luften. De väljs från uppsättningen av alla möjliga värden för ett objektattribut, som kallas domänen. Således väljs värdena i materialkolumnen från en uppsättning namn på alla möjliga material - plast, trä, metaller etc. Därför är det i princip omöjligt att ett värde visas i kolumnen Material som inte finns i motsvarande domän, till exempel "vatten" eller "sand".

Varje kolumn har ett namn, som vanligtvis skrivs överst i tabellen ( Ris. 1). Det måste vara unikt i tabellen, men olika tabeller kan ha kolumner med samma namn. Alla tabeller måste ha minst en kolumn; Kolumnerna är ordnade i tabellen i den ordning som deras namn dök upp när den skapades. Till skillnad från kolumner har rader inga namn; deras ordning i tabellen är inte definierad, och deras antal är logiskt sett obegränsat.

Figur 1. Grundläggande databaskoncept.

Eftersom raderna i tabellen inte är ordnade är det omöjligt att välja en rad efter dess position - det finns ingen "första", "andra" eller "sista" bland dem. Varje tabell har en eller flera kolumner, vars värden unikt identifierar var och en av dess rader. Denna kolumn (eller kombination av kolumner) kallas en primärnyckel. I tabellen Del är den primära nyckeln kolumnen Artikelnummer. I vårt exempel har varje del i lagret ett enda nummer, med vilket den nödvändiga informationen hämtas från Part-tabellen. Därför är den primära nyckeln i denna tabell kolumnen Part Number. Det kan inte finnas dubbletter av värden i den här kolumnen - det ska inte finnas några rader i deltabellen som har samma värde i kolumnen Part Number. Om en tabell uppfyller detta krav kallas det en relation.

Relationen mellan tabeller är den viktigaste delen av relationsdatamodellen. Det stöds av främmande nycklar. Låt oss betrakta ett exempel där en databas lagrar information om vanliga anställda (Employee table) och chefer (Manager table) i någon organisation ( Ris. 2). Den primära nyckeln för tabellen Head är kolumnen Nummer (till exempel personalnummer). Kolumnen Efternamn kan inte fungera som en primärnyckel, eftersom två chefer med samma efternamn kan arbeta i samma organisation. Varje anställd är underställd en enda chef, vilket måste återspeglas i databasen. Medarbetartabellen innehåller en kolumn Chefsnummer, och värdena i denna kolumn väljs från kolumnen Antal i chefstabellen (se. Ris. 2). Kolumnen Chefsnummer är en främmande nyckel i tabellen Anställd.

Figur 2. Relation mellan databastabeller.

Tabeller kan inte lagras och bearbetas om det inte finns "data om data" i databasen, såsom handtag för tabeller, kolumner osv. De brukar kallas metadata. Metadata presenteras också i tabellform och lagras i en dataordbok.

Förutom tabeller kan databasen lagra andra objekt, såsom visningar, rapporter, vyer och till och med applikationsprogram som fungerar med databasen.

För användare av ett informationssystem räcker det inte att databasen bara återspeglar verkliga objekt. Det är viktigt att en sådan reflektion är entydig och konsekvent. I det här fallet sägs databasen uppfylla integritetsvillkoret.

För att garantera riktigheten och ömsesidig överensstämmelse mellan data, införs vissa begränsningar för databasen, som kallas dataintegritetsbegränsningar.

Det finns flera typer av integritetsbegränsningar. Det krävs till exempel att värdena i en tabellkolumn endast väljs från motsvarande domän. I praktiken beaktas även mer komplexa integritetsbegränsningar, till exempel referensintegritet. Dess kärna är att en främmande nyckel inte kan vara en pekare till en obefintlig rad i tabellen. Integritetsbegränsningar implementeras med hjälp av speciella medel, som kommer att diskuteras i Sec.Databasserver .

SQL-språk

Själva data i datorform är inte av intresse för användaren om det inte finns några sätt att komma åt dem. Data nås i form av databasfrågor som är formulerade i ett standardfrågespråk. Idag, för de flesta DBMS, är detta språk SQL.

Framväxten och utvecklingen av detta språk som ett sätt att beskriva databasåtkomst är förknippat med skapandet av teorin om relationsdatabaser. Prototypen av SQL-språket uppstod 1970 som en del av System/R-forskningsprojektet, som arbetet utfördes vid Santa Teresa-laboratoriet hos IBM. Numera är SQL standardgränssnittet med relationell DBMS. Dess popularitet är så stor att utvecklare av icke-relationella DBMS:er (till exempel Adabas) förser sina system med ett SQL-gränssnitt.

SQL-språket har en officiell standard - ANSI/ISO. De flesta DBMS-utvecklare följer denna standard, men utökar den ofta för att implementera nya databehandlingsmöjligheter. Nya datahanteringsmekanismer som kommer att beskrivas i Sec.Databasserver , kan endast användas genom speciella SQL-satser, som vanligtvis inte ingår i språkstandarden.

SQL är inte ett traditionellt programmeringsspråk. Det skrivs inte program i den, utan frågor till databasen. Det är därför SQL är ett deklarativt språk. Det betyder att den kan användas för att formulera vad som behöver erhållas, men den kan inte ange hur det ska göras. I synnerhet, till skillnad från procedurprogrammeringsspråk (C, Pascal, Ada), har SQL-språket inte operatorer som if-then-else, for, while, etc.

Vi kommer inte att gå in i detalj om språkets syntax. Vi kommer endast att beröra det i den utsträckning som är nödvändig för att förstå enkla exempel. Med deras hjälp kommer de mest intressanta databehandlingsmekanismerna att illustreras.

En SQL-fråga består av en eller flera satser, den ena efter den andra, separerade med semikolon. Tabell 1 nedan listar de viktigaste operatorerna som ingår i ANSI/ISO SQL-standarden.

Tabell 1. Grundläggande SQL-operatorer.

SQL-frågor använder namn som unikt identifierar databasobjekt. I synnerhet är detta tabellnamnet (Detalj), kolumnnamnet (Titel), samt namnen på andra objekt i databasen som tillhör ytterligare typer (till exempel namn på procedurer och regler), som kommer att diskuteras i Sec.Databasserver . Tillsammans med enkla används också komplexa namn - till exempel bestämmer ett kvalificerat kolumnnamn namnet på kolumnen och namnet på tabellen som den tillhör (Part.Weight). För enkelhetens skull kommer namn i exemplen att skrivas på ryska, även om detta i praktiken inte rekommenderas.

Varje kolumn i en tabell lagrar specifika typer av data. Det finns grundläggande datatyper - teckensträngar med fast längd, heltal och reella tal, och ytterligare datatyper - teckensträngar med variabel längd, monetära enheter, datum och tid, logiska data (två värden - "TRUE" och "FALSE" ). I SQL kan du använda numeriska, sträng-, tecken- och datum- och tidskonstanter.

Låt oss titta på några exempel.

Frågan "bestäm antalet delar i lager för alla typer av delar" implementeras enligt följande:

VÄLJ namn, kvantitet

FRÅN Del;

Resultatet av frågan blir en tabell med två kolumner - Namn och Kvantitet, som är hämtade från den ursprungliga deltabellen. I huvudsak låter den här frågan dig få en vertikal projektion av den ursprungliga tabellen (mer strikt, en vertikal delmängd av uppsättningen tabellrader). Från alla rader i deltabellen bildas rader som inkluderar värden hämtade från två kolumner - Namn och Kvantitet.

Frågan "Vilka ståldelar finns i lager formulerad i SQL ser ut så här:

FRÅN Del

WHERE Material = "Stål";

Resultatet av denna fråga blir också en tabell som endast innehåller de rader i källtabellen som har värdet "Stål" i kolumnen Material. Den här frågan låter dig få en horisontell projektion av deltabellen (stjärnan i SELECT-satsen betyder att du väljer alla kolumner från tabellen).

Begäran "att bestämma namnet och antalet delar i lager som är gjorda av plast och väger mindre än fem kilogram" kommer att skrivas enligt följande:

VÄLJ namn, kvantitet

FRÅN Del

WHERE Material = "Plast"

OCH Vikt< 5;

Resultatet av frågan är en tabell med två kolumner - Namn, Kvantitet, som innehåller namn och antal delar av plast som väger mindre än 5 kg. I huvudsak är provtagningen operationen att först bilda en horisontell projektion (hitta alla rader i deltabellen för vilka Material = "Plast" och Vikt< 5), а затем вертикальной проекции (извлечь Название и Количество из выбранных ранее строк).

Ett av verktygen som ger snabb åtkomst till tabeller är index. Ett index är en databasstruktur som är en pekare till en specifik rad i en tabell. Ett databasindex används på samma sätt som ett register i en bok. Den innehåller värden tagna från en eller flera kolumner i en viss tabellrad och en referens till den raden. Värdena i indexet är ordnade, vilket gör att DBMS snabbt kan söka i tabellen.

Låt oss anta att en fråga formuleras till Warehouse-databasen:

VÄLJ Namn Kvantitet, Material

FRÅN Del

WHERE Number = "T145-A8";

Om det inte finns några index för en given tabell måste DBMS för att utföra denna fråga skanna hela deltabellen, sekventiellt välja rader från den och kontrollera urvalsvillkoren för var och en av dem. För stora tabeller kommer en sådan fråga att ta mycket lång tid att slutföra.

Om ett index tidigare skapats i kolumnen Tabellnummerdetaljer, kommer söktiden i tabellen att reduceras till ett minimum. Indexet kommer att innehålla värdena från nummerkolumnen och en länk till raden med detta värde i deltabellen. När en fråga körs, kommer DBMS först att hitta värdet "T145-A8" i indexet (och gör detta snabbt, eftersom indexet är beställt och dess rader är små), och sedan, med hjälp av länken i indexet, bestämma fysisk plats för den sökta raden.

Ett index skapas med SQL CREATE INDEX-satsen. I detta exempel är operatören

SKAPA UNIKT INDEX Delindex

ON Part(Nummer);

kommer att skapa ett index med namnet "Part Index" i kolumnen Number of the table Part.

För en DBMS-användare är det inte de enskilda SQL-satserna som är av intresse, utan en viss sekvens av dem, utformade som en helhet och vettiga ur hans synvinkel. Varje sådan sekvens av SQL-satser implementerar en specifik åtgärd på databasen. Det utförs i flera steg, varvid vissa operationer utförs på databastabellerna. I banksystemet genomförs således överföringen av ett visst belopp från ett korttidskonto till ett långtidskonto i flera operationer. Bland dem är att ta ut ett belopp från ett korttidskonto och kreditera det till ett långtidskonto.

Om det uppstår ett misslyckande under denna åtgärd, till exempel när den första operationen är klar men den andra inte är det, kommer pengarna att gå förlorade. Därför måste alla åtgärder på databasen utföras helt eller inte alls. Denna åtgärd kallas en transaktion.

Transaktionsbearbetning bygger på en logg, som används för att återställa transaktioner och återställa tillståndet för databasen. Mer information om transaktioner kommer att diskuteras i Sec.Transaktionshantering .

Som avslutning på vår diskussion om SQL-språket, låt oss återigen betona att det är ett frågespråk. Det är omöjligt att skriva något komplext applikationsprogram som fungerar med en databas. För detta ändamål använder moderna DBMS:er fjärde generationens språk (Forth Generation Language - 4GL), som har både de grundläggande funktionerna för tredje generationens procedurspråk (3GL), såsom C, Pascal, Ada, och förmågan att bädda in SQL uttalanden i programtexten, såväl som användargränssnittskontroller (menyer, formulär, användarinmatning, etc.). Idag är 4GL en av de facto-standarderna för utvecklingsverktyg för databasapplikationer.

DBMS-funktioner.

DBMS-funktioner är av hög och låg nivå.

Funktioner på hög nivå:

1. Data Definition – med den här funktionen bestäms vilken information som ska lagras i databasen (typ, dataegenskaper och hur de kommer att relateras till varandra).

2. Databehandling. Information kan bearbetas på olika sätt: urval, filtrering, sortering, kombinera en information med en annan, beräkna totaler.

3. Datahantering. Med den här funktionen anger du vem som får se uppgifterna, korrigera dem eller lägga till ny information och definierar även reglerna för kollektiv åtkomst.

Lågnivåfunktioner:

1. Hantera data i externt minne;

2. Hantera RAM-buffertar;

3. Transaktionshantering;

4. Mata in en ändringslogg i databasen;

5. Säkerställande av databasens integritet och säkerhet.

Transaktion är en odelbar sekvens av operationer som övervakas av DBMS från början till slutförandet, och i vilken, om en operation inte slutförs, hela sekvensen avbryts.

DBMS-logg – en speciell databas eller del av huvuddatabasen, otillgänglig för användaren och används för att registrera information om alla ändringar i databasen.

Introduktion till DBMS-logg är utformad för att säkerställa tillförlitlig lagring i databasen i närvaro av hårdvarufel och fel, samt fel i programvara.

Databasintegritet – detta är en egenskap hos en databas, vilket innebär att den innehåller fullständig, konsekvent och adekvat reflekterande information om ämnesområdet.

Klassificering av DBMS.

DBMS kan klassificeras:

1. Efter typ av program:

a. Databasservrar (till exempel MS SQL Server, InterBase (Borland)) – är avsedda för att organisera databehandlingscenter i datornätverk och implementera databashanteringsfunktioner som efterfrågas av klientprogram med hjälp av SQL-satser (d.v.s. program som svarar på förfrågningar);

b. Databasklienter – program som begär data. PFDBMS, kalkylblad, ordbehandlare och e-postprogram kan användas som klientprogram;

c. Fullt fungerande databaser (MS Access, MS Fox Pro) – ett program som har ett utvecklat gränssnitt som låter dig skapa och ändra tabeller, ange data, skapa och formatera frågor, utveckla rapporter och skriva ut dem.

2. Enligt DBMS-datamodellen (liksom databasen):

a. Hierarkisk – baserad på en trädstruktur för lagring av information och som påminner om ett datorfilsystem; den största nackdelen är oförmågan att implementera många-till-många-relationen;

b. Nätverk – som ersatte hierarkiska och inte varade länge eftersom den största nackdelen var svårigheten att utveckla seriösa applikationer. Huvudskillnaden mellan ett nätverk och ett hierarkiskt är att i en hierarkisk struktur har "post-ättling" bara en förfader, men i en nätverksavkomling kan den ha hur många förfäder som helst;

c. Relationellt – vars data placeras i tabeller, mellan vilka det finns vissa kopplingar;

d. Objektorienterad – de lagrar data i form av objekt och den största fördelen när man arbetar med dem är att ett objektorienterat tillvägagångssätt kan tillämpas på dem;

e. Hybrid, dvs objektrelationell – kombinera förmågan hos relationella och objektorienterade databaser. Ett exempel på en sådan databas är Oracle (tidigare var den relationell).

3. Beroende på platsen för de enskilda delarna av DBMS särskiljs de:

a. lokal – vars alla delar finns på en dator;

b. nätverk.

Nätverk inkluderar:

- med filserverorganisation;

Med denna organisation finns all data på en dator, som kallas en filserver, och som är ansluten till nätverket. När den nödvändiga informationen hittas överförs hela filen, inklusive en hel del redundant information. Och endast när du skapar en lokal kopia hittas den nödvändiga posten.

- med en klient-server-organisation;

Databasservern tar emot en begäran från klienten, hittar den nödvändiga posten i data och överför den till klienten. En förfrågan till servern bildas i det strukturerade frågespråket SQL, varför databasservrar kallas SQL-servrar.

- distribuerade DBMS innehåller flera tiotals och hundratals servrar placerade över ett stort område.

Grundläggande bestämmelser för relationsdatabasmodellen.

Relationsdatabas är en databas där all data är organiserad i form av tabeller, och alla operationer på denna data reduceras till operationer på tabeller.

Funktioner hos relationsdatabaser:

1. Data lagras i tabeller som består av kolumner och rader;

2. I skärningspunkten mellan varje kolumn och rad finns ett värde;

3. Varje kolumn - fält har sitt eget namn, som fungerar som dess namn - attribut, och alla värden i en kolumn har samma typ;

4. Kolumner är ordnade i en specifik ordning, som anges när tabellen skapas, till skillnad från rader, som är ordnade i slumpmässig ordning. Tabellen får inte ha en enda rad, men den måste ha minst en kolumn.

Relationsdatabasterminologi:

Vid design av en relationsdatabas placeras data i flera tabeller. Relationer upprättas mellan tabeller med hjälp av nycklar. Vid länkning av tabeller särskiljs en huvud- och en extra (underordnad) tabell.

Det finns följande typer av relationer mellan tabeller:

1. 1:1-förhållande (en till en) betyder att varje post i huvudtabellen motsvarar en post i tilläggstabellen och omvänt motsvarar varje post i tilläggstabellen en post i huvudtabellen.

2. Kommunikationstyp 1:M (en till många) betyder att varje post i huvudtabellen motsvarar flera poster i tilläggstabellen och omvänt motsvarar varje post i tilläggstabellen endast en post i huvudtabellen.

3. Relationstyp M:1 (många till en) betyder att en eller flera poster i huvudtabellen endast motsvarar en post i den sekundära tabellen.

4. M:M relation (många till många) – det här är när flera poster i huvudtabellen motsvarar flera poster i den extra tabellen och vice versa.

5. Grundläggande komponenter i MS Access.

Huvudkomponenterna (objekten) i MS Access är:

1. Tabeller;

3. Blanketter;

4. Rapporter;

5. Makron:

Moduler

Tabell är ett objekt utformat för att lagra data i form av poster (rader) och fält (kolumner). Varje fält innehåller en annan del av en post, och varje tabell används för att lagra information om ett specifikt problem.

Begäran – en fråga om data lagrad i tabeller, eller instruktioner för att välja poster som ska ändras.

Form är ett objekt i vilket du kan placera kontroller avsedda för att mata in, visa och ändra data i tabellfält.

Rapportera är ett objekt som låter dig presentera användardefinierad information i en viss form, visa och skriva ut den.

Makro – ett eller flera makrokommandon som kan användas för att automatisera en specifik uppgift. Ett makro är den grundläggande byggstenen i ett makro; en fristående instruktion som kan kombineras med andra makroinstruktioner för att automatisera slutförandet av en uppgift.

Modul – en uppsättning beskrivningar, instruktioner och procedurer lagrade under ett namn. MS Access har tre typer av moduler: formulärmodul, rapportmodul och allmän modul. Formulär- och rapportmoduler innehåller lokala program för formulär och rapporter.

6. Tabeller i MS Access.

MS Access har följande metoder för att skapa tabeller:

1. Tabellläge;

2. Konstruktör;

3. Tabell Wizard;

4. Importera tabeller;

5. Kommunikation med tabeller.

I tabellläge Data läggs in i en tom tabell. En tabell med 30 fält tillhandahålls för datainmatning. Efter att ha sparat den bestämmer MS Access själv vilken datatyp som ska tilldelas varje fält.

Konstruktör ger möjlighet att självständigt skapa fält, välja datatyper för fält, fältstorlekar och ställa in fältegenskaper.

För att definiera ett fält i läge Konstruktör tillfrågas:

1. Fält namn , som i varje tabell måste ha ett unikt namn, som är en kombination av bokstäver, siffror, mellanslag och specialtecken, med undantag för " .!” “ " Den maximala namnlängden är 64 tecken.

2. Data typ definierar typen och intervallet för giltiga värden, såväl som mängden minne som allokerats för detta fält.

MS Access-datatyper

3. De viktigaste fältegenskaperna:

- Fältstorlek anger den maximala storleken på data som lagras i fältet.

- Fältformatär ett format för att visa en given datatyp och anger reglerna för att presentera data när den visas på skärmen eller skrivs ut.

- Fältsignatur anger texten som visas i tabeller, formulär och rapporter.

- Villkor på värde låter dig styra inmatning, ställer in begränsningar för inmatade värden, om villkoren överträds, förbjuder inmatning och visar texten som anges av egenskapen Felmeddelande;

- Felmeddelande ställer in texten i meddelandet som visas på skärmen när de begränsningar som anges av värdevillkoret överträds.

Kontrolltyp– en egenskap som ställs in på fliken Substitution i tabelldesignerfönstret. Den här egenskapen avgör om fältet ska visas i tabellen och i vilken form - som ett fält eller en kombinationsruta.

Unik (primär) nyckel tabeller kan vara enkla eller komplexa, inklusive flera fält.

För att definiera en nyckel, välj fälten som utgör nyckeln och klicka på knappen i verktygsfältet nyckelfält eller kommandot körs Redigera/nyckelfält.

©2015-2019 webbplats
Alla rättigheter tillhör deras upphovsmän. Denna webbplats gör inte anspråk på författarskap, men erbjuder gratis användning.
Sidans skapande datum: 2016-02-16