RMD uppfanns och utvecklades av E. Codd 1970. Hans följare är Date.

RMD bygger på konceptet set-teoretisk relation .

Attityd är en tvådimensionell tabell som innehåller vissa data.

Väsen är ett objekt av vilken karaktär som helst, vars data lagras i databasen.

Attribut är en egenskap som kännetecknar en enhet.

Låt D 1 ,D 2 ,...,D n –n-mängder ges,

Då är relationen R mängden ordnade tupler d i єD i, där di är ett attribut, Di är en domän.

Exempel:

Anställd

Förhållande arity (power) är det totala antalet attribut i relationen.

kardinalnummer (kardinalitet av relationer) är antalet av alla olika tupler i relationerna R.

attityd någon delmängd av den kartesiska produkten, inklusive en eller flera domäner, kallas.

Ex: det finns många

D 1* D 2* D3 =((A,B,3),(A,B,4),(A,B,5),(A,C,3),(A,C,4), (A,C,5),(2,B,3),(2,B,4),(2,B,5),(2,C,3),(2,C,4),

Relationsdiagram kallas en ändlig uppsättning namn på attribut för relationen.

Domän är uppsättningen av alla möjliga värden för något relationsattribut.

En relation kan ha flera kombinationer av attribut, som var och en unikt identifierar alla tuplar i relationen. Sådana kombinationer kallas möjliga relationsnycklar (potentiella nycklar).

En delmängd av attribut P av en relation R kallas en kandidatnyckel (möjlig nyckel) om följande två villkor är uppfyllda:

i relation R kan det inte finnas två olika tupler med samma värde (detta kallas unikhetsegenskapen).

ingen delmängd av P har unikhetsegenskapen.

Kandidatnycklar fungerar som det enda sättet att adressera på tupelnivåerna i en relation. primärnyckel kallas ett attribut (eller en uppsättning attribut) för en relation som unikt identifierar var och en av tuplarna i denna relation.

Varje relation har nödvändigtvis en kombination av attribut som kan fungera som en nyckel. Detta garanteras av det faktum att en relation är en mängd som inte innehåller samma tupler.

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

eliminering av duplicering av nyckelattributvärden.

tupel beställning.

påskynda arbetet med relationstuplar.

organisering av länkningstabeller.

Låt relation R1 ha ett icke-nyckelattribut A vars värde är värdet av nyckelattribut B i en annan relation R2, då sägs attribut A för relation R1 vara främmande nyckel .

Vilken relation som helst kan representeras som en tabell, men inte varje tabell är en relation. För att en godtycklig tabell ska vara en relation måste fyra villkor vara uppfyllda:

alla poster måste ha samma struktur.

varje post i tabellen måste vara unik.

värdet på elementen i en kolumn måste tillhöra samma domän.

kolumnnamn måste vara unika.

LÄGG TILL– Denna operation rapporterar fel i följande fall:

Tupeln som läggs till matchar inte relationsschemat.

Något tuppelvärde hör inte till motsvarande domän.

Tupeln har samma nyckel som tupeln redan i relationen.

DEL – för att radera räcker det att ange värdet på nyckeln på fjärrtupelen. Ett fel uppstår endast om tuppeln som ska tas bort inte finns i relationen.

CH – för denna operation uppstår alla lägg till och ta bort fel.

1.2 Relationell databasteori

En relationsdatabas är en samling relationer som innehåller all information som behöver lagras i en databas. Det vill säga, databasen representerar en uppsättning tabeller som krävs för att lagra all data. Relationsdatabastabeller är logiskt relaterade

Alltså målet informationssystemär behandlingen av data om objekt i den verkliga världen, med hänsyn till relationerna mellan objekt. I databasteorin kallas data ofta för attribut och objekt som entiteter. Objekt, attribut och relation är de grundläggande begreppen för IS.

Ett objekt (eller entitet) är något som finns och är särskiljbart, det vill säga ett objekt kan kallas det där "något" som det finns ett namn för och ett sätt att skilja ett liknande objekt från ett annat. Objekt kan inte bara vara materiella objekt, utan också mer abstrakta begrepp som speglar den verkliga världen.

Ett attribut (eller data) är någon indikator som kännetecknar ett visst objekt och tar något numeriskt, textuellt eller annat värde för en viss instans av objektet. Informationssystemet fungerar med uppsättningar av objekt utformade i relation till ett givet ämnesområde, med hjälp av specifika värden av attribut (data) för vissa objekt.

Utvecklingen av relationsdatabaser började i slutet av 60-talet, när de första tidningarna dök upp som diskuterade; möjligheten att använda bekanta och naturliga sätt datapresentation - de så kallade tabelldatalogiska modellerna.

Grundaren av relationsdatabasteorin är IBM-anställd Dr. E. Codd, som publicerade artikeln A Relational Model of Data for Large-Shared Data Banks den 6 juni (juni 1970). Denna artikel användes först med termen "relationell datamodell" Teorin om relationsdatabaser, utvecklad på 70-talet i USA av Dr E. Codd, har en kraftfull matematisk grund som beskriver reglerna för effektiv dataorganisation. Den teoretiska bas som utvecklats av E. Codd blev grunden för att utveckla teorin av databasdesigndata.

E. Codd, som är matematiker till sin utbildning, föreslog att man skulle använda mängdteorin (union, skärningspunkt, skillnad, kartesisk produkt) för databehandling. Han bevisade att vilken uppsättning data som helst kan representeras som en speciell typ av tvådimensionella tabeller, kända i matematiken som "relationer".

En relationsdatabas är en sådan databas 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 tabellmanipulationer.

En tabell består av kolumner (fält) och rader (poster); har ett namn som är unikt i databasen. Tabellen återspeglar typen av det verkliga objektet (entiteten), och varje rad representerar ett specifikt objekt. Varje kolumn i tabellen är en uppsättning värden för ett visst attribut för ett objekt. Värdena väljs från uppsättningen av alla möjliga värden för ett objektattribut, som kallas domänen.

I sin mest allmänna form definieras en domän genom att specificera någon grundläggande datatyp till vilken domänens element hör, och ett godtyckligt logiskt uttryck applicerat på dataelementen. Om ett booleskt villkor på ett dataelement utvärderas till sant, så tillhör det elementet domänen. I det enklaste fallet definieras en domän som en giltig potentiell uppsättning värden av samma typ. Till exempel utgör insamlingen av födelsedatum för alla anställda en "födelsedatumdomän", och namnen på alla anställda utgör en "anställds namndomän". Födelsedatumdomänen har en datatyp som gör att du kan lagra information om tidpunkter, och domänen för anställdas namn måste ha en teckendatatyp.

Om två värden kommer från samma domän kan du jämföra de två värdena. Till exempel, om två värden kommer från en födelsedatumdomän, kan du jämföra dem för att avgöra vilken anställd som är äldre. Om värdena är hämtade från olika domäner är deras jämförelse inte tillåten, eftersom det med all sannolikhet inte är vettigt. Till exempel, genom att jämföra en anställds namn och födelsedatum, kommer det inte att bli något bestämt.

Varje kolumn (fält) har ett namn, som vanligtvis skrivs överst i tabellen. När du designar tabeller inom ett visst DBMS är det möjligt att välja dess typ för varje fält, det vill säga att bestämma en uppsättning regler för dess visning, och även att bestämma de operationer som kan utföras på data som lagras i detta fält. Uppsättningar av typer kan skilja sig åt för olika DBMS.

Fältnamnet måste vara unikt i en tabell, men olika tabeller kan ha fält med samma namn. Alla bord måste ha minst ett fält; Fälten är placerade i tabellen i den ordning som deras namn visas när tabellen skapas. Till skillnad från fält har strängar inga namn; deras ordning i tabellen är inte definierad, och antalet är inte logiskt begränsat.

Eftersom raderna i tabellen inte är ordnade är det omöjligt att välja en rad efter dess position - bland dem finns det ingen "första", "andra", "sista". Varje tabell har en eller flera kolumner, värdena som unikt identifierar var och en av dess rader. En sådan kolumn (eller kombination av kolumner) kallas en primärnyckel. Ofta introduceras ett konstgjort fält för att numrera posterna i en tabell. Ett sådant fält kan till exempel vara dess ordningsföljd, vilket kan säkerställa att varje post i tabellen är unik. Nyckeln måste ha följande egenskaper:

Unikhet. Vid varje given tidpunkt har inga två distinkta tuplar av en relation samma värde för kombinationen av attribut som ingår i nyckeln. Det vill säga att det inte kan finnas två rader i tabellen som har samma identifikationsnummer eller passnummer.

Minimalitet. Inget av attributen som ingår i nyckeln kan exkluderas från nyckeln utan att bryta mot unikheten. Det betyder att du inte ska skapa en nyckel som innehåller både passnummer och identifikationsnummer. Det räcker med att använda något av dessa attribut för att unikt identifiera en tupel. Du bör inte heller inkludera ett icke-unikt attribut i nyckeln, det vill säga det är förbjudet att använda en kombination av ett identifikationsnummer och en anställds namn som nyckel. Om du utesluter medarbetarens namn från nyckeln kan du fortfarande identifiera varje rad unikt.

Varje relation har åtminstone en möjlig nyckel, eftersom helheten av alla dess attribut uppfyller unikhetsvillkoret - detta följer av själva definitionen av relationen.

En av de möjliga nycklarna är slumpmässigt vald som primärnyckel. De återstående möjliga nycklar, om några, tas som alternativa nycklar. Till exempel, om du väljer ett identifikationsnummer som primärnyckel, kommer passnumret att vara en alternativ nyckel.

Relationen mellan tabeller är en väsentlig del av den relationella datamodellen. Det stöds av främmande nycklar.

Tabeller kan inte lagras och bearbetas om det inte finns "data om datan" i databasen, såsom tabelldeskriptorer, kolumndeskriptorer osv. De brukar kallas metadata. Metadata presenteras också i tabellform och lagras i dataordboken.

Förutom tabeller kan andra objekt lagras i databasen, såsom skärmformulär, rapporter (rapporter), vyer (vyer) och även applikationer som fungerar med databasen.

För användare av ett informationssystem räcker det inte att databasen bara återspeglar den verkliga världens 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.

Codds relationsmodell har flera begränsningar som används för att validera data i databasen, samt för att förstå strukturen på datan. Det är vanligt att markera följande begränsningar:

Kategorisk integritet;

Integritet på länknivå;

funktionella beroenden.

I den integrerade delen av relationsdatamodellen är två grundläggande integritetskrav fasta, vilka måste stödjas i alla relationella DBMS. Det första kravet kallas kravet på entitetsintegritet. Ett objekt eller entitet i den verkliga världen i relationsdatabaser motsvarar tuplar av relationer. Specifikt är kravet att varje tupel av vilket relationsvärde som helst av en relationsvariabel måste kunna särskiljas från alla andra tupel av det relationsvärdet genom de sammansatta värdena av en fördefinierad uppsättning attribut för relationsvariabeln, dvs. ord måste alla relationsvariabler ha en primärnyckel. Detta krav är automatiskt uppfyllt om de grundläggande egenskaperna för relationer inte kränks i systemet.

Hela entitetsintegritetskravet är som följer: alla relationsvariabler måste ha en primärnyckel, och inget primärnyckelvärde i relationsvariabelns värderelationstuplar måste innehålla nollvärden. För att till fullo förstå denna formulering, låt oss kort diskutera begreppet NULL.

Naturligtvis, teoretiskt sett, bör varje tupel som ingår i en lagrad relation innehålla alla egenskaper hos den verkliga världens entitet som den modellerar och som vi vill lagra i databasen. Men i praktiken är det inte säkert att alla dessa egenskaper är kända vid den tidpunkt då en enhet måste bindas till databasen.

Edgar Codd föreslog att man skulle använda nollvärden i sådana fall. Ett odefinierat värde tillhör inte någon datatyp och kan finnas bland värdena för alla attribut som definierats på vilken datatyp som helst (såvida det inte är uttryckligen förbjudet när attributet definieras).

Så, det första av kraven - kravet på entitetens integritet - innebär att primärnyckeln måste identifiera varje entitet fullständigt, och därför får inte något värde på primärnyckeln innehålla nollvärden. (I den klassiska relationsmodellen gäller detta krav även för möjliga nycklar; i SQL-orienterat DBMS stöds inte detta krav för möjliga nycklar).

Det andra kravet, kallat kravet på referensintegritet, är mer komplext. Det är uppenbart att samtidigt som normaliseringen av relationer respekteras, representeras komplexa enheter i den verkliga världen i en relationsdatabas i form av flera tuplar av flera relationer. Naturligtvis kan en främmande nyckel vara sammansatt, det vill säga den kan bestå av flera attribut. En relation där en främmande nyckel definieras sägs hänvisa till en motsvarande relation där samma attribut är primärnyckeln.

Kravet på referensintegritet, eller integritetskrav för främmande nyckel, är att för varje främmande nyckelvärde som förekommer i relationsvärde-tupeln för den refererande relationsvariabeln, eller i relationsvärdet för den refererade relationsvariabeln, måste det finnas en tupel med en sådan samma värde som primärnyckeln, eller så måste den främmande nyckelns värde vara helt odefinierat (dvs. peka på ingenting).

Det bör noteras att, precis som en primärnyckel, måste en främmande nyckel anges när en relationsvariabel definieras och är en begränsning av de tillåtna relationsvärdena för denna variabel. Med andra ord är en främmande nyckeldefinition en definition av databasintegritetsbegränsning.

Entitets- och referensintegritetsbegränsningar måste stödjas av DBMS. För att upprätthålla en entitets integritet är det tillräckligt att garantera frånvaron i någon relationsvariabel av relationsvärden som innehåller tupler med samma primära nyckelvärde (och att förbjuda förekomsten av nollvärden i primärnyckelvärdet) . Referensintegritet är lite mer komplicerat.

Det är tydligt att när man uppdaterar referensrelationen (infogning av nya tupler eller modifiering av det främmande nyckelvärdet i befintliga tupler), är det tillräckligt för att säkerställa att felaktiga främmande nyckelvärden inte visas.

Det finns tre tillvägagångssätt, som alla stöder referensintegritet. Det första tillvägagångssättet är att aldrig ta bort en refererad tuppel alls (det vill säga, du måste först antingen ta bort de refererande tuplarna eller ändra deras främmande nyckelvärden i enlighet med detta). I det andra tillvägagångssättet, när en refererad tuppel tas bort, blir värdet på den främmande nyckeln i alla refererande tuplar automatiskt helt odefinierat. Slutligen är det tredje tillvägagångssättet (kaskadradering) att när en tuppel tas bort från den refererade relationen, tas alla refererande tuplar automatiskt bort från referensrelationen.

I avancerade relationella DBMS:er kan du vanligtvis välja hur referensintegriteten ska bibehållas för varje instans av en främmande nyckeldefinition. För att fatta ett sådant beslut är det naturligtvis nödvändigt att analysera kraven för ett visst applikationsområde.

Alla företag som producerar sådana DBMS kallar dem relationssystem. Det är mycket viktigt att tydligt förstå vilka egenskaper hos sådana system som verkligen är relationella, och vad i dem som inte helt motsvarar de ursprungliga, tydliga och rigorösa idéerna om det relationella tillvägagångssättet och till och med motsäger dem. Detta kommer att hjälpa till att mer korrekt organisera databaser och bygga applikationer i en SQL-orienterad DBMS-miljö.

Datavärden lagrade i en relationsdatabas skrivs in, det vill säga typen av varje lagrat värde är känd. Konceptet med en datatyp i den relationella datamodellen överensstämmer helt med konceptet för en datatyp i programmeringsspråk. Den traditionella (icke strikta) definitionen av en datatyp består av tre huvudkomponenter: definitionen av en uppsättning värden av en given typ; definiera en uppsättning operationer som är tillämpliga på typens värden; definiera hur värdena för typen (bokstaver) representeras externt.

Vanligtvis tillåter moderna relationsdatabaser lagring av tecken, numeriska data (exakta och ungefärliga), specialiserade numeriska data (som "pengar"), såväl som speciella "temporala" data (datum, tid, tidsintervall). Dessutom stödjer relationssystem möjligheten för användare att definiera sina egna datatyper.

Konceptet med en domän är mer specifikt för databaser, även om det finns analogier med undertyper i vissa programmeringsspråk (i deras "tredje manifest" avskaffar Christopher Date och Hugh Darwen helt och hållet distinktionen mellan domän och datatyp) . I allmänhet definieras en domän genom att specificera någon grundläggande datatyp till vilken elementen i domänen hör, och ett godtyckligt logiskt uttryck applicerat på ett element av denna datatyp (domänbegränsningar). Ett dataelement är ett domänelement om och endast om detta booleska uttryck utvärderas till sant. Varje domän är associerad med ett namn som är unikt bland namnen på alla domäner i motsvarande databas.

Den mest korrekta intuitiva tolkningen av begreppet en domän är dess uppfattning som en acceptabel potentiell, begränsad delmängd av värden av en given typ. Till exempel, i bastypen av teckensträngar, men dess värden kan endast inkludera de strängar som kan representera namn (i synnerhet för att kunna representera ryska namn kan sådana strängar inte börja med ett mjukt eller hårt tecken och kan inte vara längre, till exempel 20 tecken). Om något relationsattribut är definierat på någon, spelar domänbegränsningen då rollen som en integritetsbegränsning som åläggs värdena för detta attribut.

I klassiska relationsdatabaser, när databasschemat väl definierats, kunde endast värdena för relationsvariabler ändras. Men nu i de flesta implementeringar är det också möjligt att ändra databasschemat: definiera nya och ändra rubrikerna för befintliga relationsvariabler. Detta kallas vanligen för databasschemaevolution.

Per definition är primärnyckeln för en relationsvariabel en delmängd S av dess rubrikattributuppsättning så att värdet på primärnyckeln (sammansatt om primärnyckeln innehåller mer än ett attribut) i någon tupel av relationskroppen när som helst är skiljer sig från värdet på primärnyckeln i alla andra tupelkroppar av denna relation, och ingen riktig delmängd av S har denna egenskap.

Förekomsten av en primärnyckel för varje relationsvärde är en konsekvens av en av de grundläggande egenskaperna hos relationer, nämligen egenskapen att relationskroppen är en uppsättning tuplar.

Representation av en relation i en relationsdatamodell är en tabell, vars rubrik är schemat för relationen, och raderna är tuplarna för relationsinstansen; i detta fall motsvarar attributnamnen kolumnnamnen i den givna tabellen. Därför säger de ibland om "tabellens kolumner", vilket betyder "relationsattribut".

Relationer bör aldrig innehålla dubbletter av tupler, vilket följer av definitionen av relationskroppen som en uppsättning av tupler. I klassisk mängdlära består varje mängd per definition av olika element.

Det är från den här egenskapen som varje värde i relationen har en primärnyckel - den minsta uppsättningen attribut som är en delmängd av rubriken för denna relation, vars sammansatta värde unikt bestämmer relationens tupel. I själva verket, eftersom alla tuplar i kroppen av någon relation när som helst är distinkta, har varje värde av relationen unikhetsegenskapen åtminstone för hela uppsättningen av dess attribut. I den formella definitionen av primärnyckeln krävs det dock att dess "minimalitet" säkerställs, dvs. uppsättningen av attribut för primärnyckeln bör inte inkludera sådana attribut som kan kasseras utan att det påverkar huvudegenskapen - den otvetydiga definitionen av en tuppel. Lite senare kommer vi att visa varför minimalitetsegenskapen för en primärnyckel är kritisk. Det är tydligt att om någon relation har en uppsättning attribut som har unikhetsegenskapen, så finns det också en minimiuppsättning av attribut som har unikhetsegenskapen.

Det kan finnas relationsvärden med flera icke-matchande minimiattributuppsättningar som har unika egenskaper. I det här fallet måste databasdesignern bestämma vilken av de alternativa uppsättningarna av attribut som ska anropas primärnyckeln, och de återstående minsta attributuppsättningarna som har unikhetsegenskapen kallas kandidatnycklar.

Begreppet primärnyckel är oerhört viktigt i samband med begreppet databasintegritet. Notera att även om existensen av en primärnyckel för relationsvärde formellt sett är en konsekvens av det faktum att relationskroppen är en mängd, så uppträder i praktiken de primära (och möjliga) nycklarna för relationsvariabler som ett resultat av explicita instruktioner från relationsdesignern. Genom att definiera en relationsvariabel modellerar designern den del av ämnesområdet från vilken databasen kommer att innehålla data. Och naturligtvis måste designern känna till denna datas natur.

I ett relationellt DBMS kan du inte lagra relationstupler på fysisk nivå i den ordning som utvecklarna vill ha. Frånvaron av ett krav på att upprätthålla ordning på uppsättningen av tuplar av en relation ger DBMS ytterligare flexibilitet vid lagring av databaser i externt minne och när du frågar databasen. Detta motsäger inte det faktum att när man formulerar en fråga till databasen, till exempel i SQL-språket, kan man kräva att den resulterande tabellen sorteras enligt värdena i vissa kolumner. Ett sådant resultat är generellt sett inte en relation, utan någon ordnad lista med tupler, och det kan bara vara det slutliga resultatet som inte längre kan frågas.

Enligt Datas tolkning består den relationella modellen av tre delar som beskriver olika aspekter av det relationella förhållningssättet: den strukturella delen, manipulationsdelen och den integrerade delen (K. Date, 2000).

I den strukturella delen av modellen är det fixerat att den enda generiska datastrukturen som används i relationsdatabaser är en normaliserad parrelation. Begreppen domäner, attribut, tuples, header, body och relationsvariabel definieras. I själva verket var det begreppen och egenskaperna hos den strukturella komponenten i relationsmodellen som övervägdes ovan.

I manipulationsdelen av modellen definieras två grundläggande mekanismer för att manipulera relationsdatabaser – relationalgebra och relationskalkyl. Den första mekanismen är baserad huvudsakligen på den klassiska mängdteorin (med vissa förfinningar och tillägg), och den andra är baserad på den klassiska logiska apparaten i första ordningens predikatkalkyl. Huvudfunktionen för manipulationsdelen av relationsmodellen är att ge ett mått på relationaliteten hos ett visst relationsdatabasspråk: ett språk kallas relationellt om det inte har mindre uttrycksfullhet och kraft än relationalgebra eller relationskalkyl.

Av det föregående följer att den klassiska metoden för att utforma relationsdatabasstrukturer har följande problem:

1. identifiering av funktionella beroenden;

2. komplexiteten i att identifiera alla funktionella beroenden;

3. Det slutliga designresultatets beroende av designerns erfarenhet och subjektiva syn, och inte av den formella designmetoden;

4. Problemet med att identifiera enheter och entitetsattribut.

1.3 DB IS designmetoder

Metodiken för att skapa informationssystem är att organisera processen för att bygga ett informationssystem och att hantera denna process för att säkerställa att kraven uppfylls både för själva systemet och för utvecklingsprocessens egenskaper.

Huvuduppgifterna, vars lösning bör tillhandahållas av metoden för att skapa informationssystem (IS) (med hjälp av en lämplig uppsättning verktyg), är:

Överensstämmelse med det skapade informationssystemet med företagets mål och mål, såväl som kraven för att det ska automatisera de önskade processerna och garantera skapandet av ett system med givna parametrar inom en given tid inom en förutbestämd budget;

Enkelt underhåll, modifiering och utbyggnad av systemet för att säkerställa dess överensstämmelse med de förändrade förhållandena för företaget och överensstämmelse med det skapade informationssystemet med kraven på öppenhet, portabilitet och skalbarhet;

Möjlighet att i det skapade systemet använda de verktyg som utvecklats tidigare och som används på företaget informationsteknik (programvara, databaser, verktyg datavetenskap, telekommunikation).

Metoder, teknologier och designverktyg (CASE-verktyg) ligger till grund för utformningen av alla informationssystem. Metodiken implementeras genom specifika teknologier och deras stödjande standarder, metoder och verktyg som säkerställer utförande av processer livscykel informationssystem.

1. En given sekvens av utförande av tekniska designoperationer;

2. Kriterier och regler som används för att utvärdera resultaten av tekniska operationer.

3. Grafiska och textuella medel (notationer) som används för att beskriva systemet som designas.

Dessutom måste varje teknisk verksamhet förses med lämpligt material, information och mänskliga resurser. (Data som erhållits vid föregående operation (eller initiala data), presenterade i en standardform, läromedel, instruktioner, föreskrifter och standarder, mjukvara och hårdvara och utförare).

Resultaten av operationen bör presenteras i någon standardform, vilket säkerställer att de uppfattas på ett adekvat sätt under nästa tekniska operation (där de kommer att användas som indata). Tekniken för att designa, utveckla och underhålla informationssystem måste uppfylla ett antal allmänna regler:

Upprätthålla hela livscykeln för informationssystemet;

Ge möjligheten att hantera projektkonfigurationen, underhålla versioner av projektet och dess komponenter, automatiskt släppa projektdokumentation och synkronisera dess versioner med projektversioner;

Säkerställa garanterad måluppfyllelse att utveckla ett system med en given kvalitet vid en bestämd tidpunkt och möjlighet att dela upp (nedbryta) stora projekt i ett antal delsystem, som t.ex. beståndsdelar, utvecklad av grupper av artister av ett begränsat antal, med efterföljande integration av dessa delar;

Att ge möjlighet att bedriva arbete med design av enskilda delsystem i små grupper, vilket beror på principerna för teamledning och öka produktiviteten genom att minimera antalet externa länkar.

Säkerställ minsta tid för att få ett fungerande system. (implementering av informationssystemet inte som en helhet, utan utveckling och implementering av dess individuella delsystem);

Säkerställa oberoendet för de exekverade designlösningarna från sätten att implementera systemet - databashanteringssystem, operativ system, programmeringsspråk och system.

På inledande skede förekomsten av datorinformationssystem, deras utveckling skedde i traditionella programmeringsspråk. Men eftersom komplexiteten hos system som utvecklas och användarnas önskemål ökar, tack vare tekniska framsteg och framväxten av ett bekvämt grafiskt användargränssnitt i systemprogramvaran. En metodik för att skapa informationssystem baserade på användningen av snabba applikationsutvecklingsverktyg har vuxit fram, som nyligen har blivit utbredd och har blivit känd som Rapid Application Development Methodology (RAD). Denna metod täcker alla stadier av livscykeln för moderna informationssystem och är en uppsättning specialverktyg som låter dig arbeta med en viss uppsättning grafiska objekt som funktionellt visar individuella informationskomponenter i applikationer.

En metod för snabb applikationsutveckling förstås vanligtvis som en utvecklingsprocess för informationssystem baserad på tre huvudelement:

På ett litet team av programmerare (vanligtvis från 2 till 10 personer);

På ett noggrant utformat produktionsschema, utformat för en relativt kortsiktigt utvecklingen;

På en iterativ utvecklingsmodell baserad på nära interaktion med kunden, när utvecklare, allt eftersom projektet fortskrider, förfinar och implementerar de krav som kunden ställer i produkten.

Huvudprinciperna för RAD-metodiken är att en iterativ (spiral)utvecklingsmodell används. Fullständigt slutförande av arbetet i vart och ett av stadierna av livscykeln är inte nödvändigt. I processen att utveckla ett informationssystem, utfört av ett litet och välskött team av professionella, säkerställs en nära interaktion med kunden och framtida användare. CASE-verktyg och verktyg för snabb applikationsutveckling används, samt verktyg för konfigurationshantering som underlättar att göra ändringar i projektet och underhålla det färdiga systemet. Prototyper används för att bättre förstå och förverkliga slutanvändarens behov. Testning och utveckling av projektet genomförs samtidigt med utvecklingen. Kompetent ledning av systemutveckling, tydlig planering och kontroll av arbetsprestationer tillhandahålls.

CASE-verktyg (från Computer Aided Software / System Engineering) - låter dig designa vilket system som helst på en dator. Ett nödvändigt inslag i system- och strukturell-funktionell analys, CASE-verktyg låter dig modellera affärsprocesser, databaser, programvarukomponenter, aktiviteter och struktur i organisationer

Tillämplig inom nästan alla verksamhetsområden. Resultatet av att använda CASE-verktyg är systemoptimering, kostnadsreduktion, effektivitetsökning, minskning av felsannolikhet.

RAD-verktyg gjorde det möjligt att implementera en helt annan teknik för att skapa applikationer jämfört med den traditionella. Informationsobjekt bildas som någon form av driftsmodeller (prototyper), vars funktion överensstämmer med användaren, och sedan kan utvecklaren gå direkt till bildandet av kompletta applikationer utan att förlora den övergripande bilden av det designade systemet ur sikte.

Förmågan att använda detta tillvägagångssätt är till stor del resultatet av tillämpningen av principerna för objektorienterad design (OOP). Dessa principer gör det möjligt att övervinna en av de största svårigheterna som uppstår vid utvecklingen av komplexa system. En enorm klyfta mellan den verkliga världen (ämnesområdet) och den simulerande miljön.

De låter dig också skapa en beskrivning (modell) av ämnesområdet i form av en uppsättning objekt - enheter som kombinerar data och metoder för att bearbeta dessa data (procedurer). Där varje objekt har sitt eget beteende och modellerar något objekt av den verkliga världen. Ur denna synvinkel är föremålet ganska påtagligt och uppvisar ett visst beteende.

PÅ objekt tillvägagångssätt tyngdpunkten flyttas till de specifika egenskaperna hos det fysiska eller abstrakta system som är föremål för mjukvarumodellering. Objekt har integritet som inte kan kränkas. Därmed förblir de egenskaper som kännetecknar objektet och dess beteende oförändrade. Ett objekt kan bara ändra tillstånd, kontrolleras eller stå i en viss relation till andra objekt.

Objektorienterad design har blivit utbredd med tillkomsten av visuella programmeringsverktyg som ger sammanslagning (inkapsling) av data med procedurer som beskriver beteendet hos verkliga objekt till programobjekt som kan visas på ett visst sätt i en grafisk användarmiljö. Detta gjorde det möjligt att börja skapa mjukvarusystem som är så lika verkliga som möjligt och att uppnå den högsta abstraktionsnivån. I sin tur låter objektorienterad programmering dig skapa mer tillförlitliga koder, eftersom programobjekt har ett väldefinierat och hårt kontrollerat gränssnitt.

När man utvecklar applikationer med RAD-verktyg finns det många färdiga objekt som lagras i ett offentligt lager. Men det finns också möjlighet att utveckla nya anläggningar. Samtidigt kan nya objekt utvecklas både utifrån befintliga och från grunden.

RAD-verktygen har en bekväm GUI användare och låter dig skapa enkla applikationer baserade på standardobjekt utan att skriva programkod. Detta är en stor fördel med RAD, eftersom det avsevärt minskar rutinarbetet med att utveckla användargränssnitt (att använda konventionella verktyg, att utveckla gränssnitt är en ganska mödosam uppgift, vars lösning tar mycket tid). Hög hastighet utveckling av gränssnittsdelen av applikationer gör att du snabbt kan skapa prototyper och förenklar interaktion med slutanvändare.

Således tillåter RAD-verktyg utvecklare att fokusera på kärnan i de verkliga produktionsprocesserna för institutionen för vilken informationssystemet skapas. Detta leder till en höjning av kvaliteten på det utvecklade systemet.

Tänk på en strukturell designstrategi. Kärnan i det strukturella tillvägagångssättet för utvecklingen av IS ligger i dess nedbrytning (uppdelning) i automatiserade funktioner: systemet är uppdelat i funktionella delsystem, som i sin tur är indelade i underfunktioner, indelade i uppgifter osv. Partitioneringsprocessen fortsätter upp till specifika procedurer. Samtidigt behåller det automatiserade systemet en helhetssyn där alla komponenter är sammankopplade. När man utvecklar ett system "bottom-up" från enskilda uppgifter till hela systemet går integriteten förlorad, problem uppstår i informationsdockning av enskilda komponenter.

Alla de vanligaste metoderna för det strukturella tillvägagångssättet är baserade på ett antal generella principer. Följande två grundläggande principer används:

Principen om "dela och härska" - principen att lösa komplexa problem genom att bryta ner dem i många mindre självständiga uppgifter som är lätta att förstå och lösa;

Principen för hierarkisk ordning är principen att organisera de beståndsdelar av ett problem i hierarkiska trädstrukturer med tillägg av nya detaljer på varje nivå.

Valet av två grundläggande principer betyder inte att de andra principerna är sekundära, eftersom att ignorera någon av dem kan leda till oförutsägbara konsekvenser (inklusive att hela projektet misslyckas). De viktigaste av dessa principer är följande:

Abstraktionsprincipen - är att lyfta fram de väsentliga aspekterna av systemet och distrahera från det oväsentliga;

Principen om formalisering - ligger i behovet av ett strikt metodologiskt tillvägagångssätt för att lösa problemet;

Konsistensprincipen - ligger i elementens giltighet och konsekvens;

Principen för datastrukturering är att data ska vara strukturerade och hierarkiskt organiserade.

I strukturanalys används huvudsakligen två grupper av verktyg som illustrerar de funktioner som systemet utför och relationerna mellan data. Varje grupp av verktyg motsvarar vissa typer av modeller (diagram), av vilka de vanligaste är: ERD (Entity-Relationship Diagrams) "Entity-Relationship Diagrams".

På IS designstadiet utökas, förfinas och kompletteras modellerna med diagram som speglar mjukvarustrukturen: mjukvaruarkitektur, blockdiagram program och skärmdiagram.

Semantisk modell (konceptuell modell, infologisk modell) är en domänmodell utformad för att representera domänens semantik på den högsta abstraktionsnivån. Detta innebär att behovet av att använda de "lågnivå"-koncept som är förknippade med detaljerna i den fysiska representationen och lagringen av data elimineras eller minimeras.

Semantisk modellering har varit föremål för intensiv forskning sedan slutet av 1970-talet. Huvudmotivet för sådana studier (d.v.s. problemet som forskarna försökte lösa) var följande faktum. Faktum är att databassystem vanligtvis har mycket begränsad kunskap om innebörden av de data som lagras i dem. Oftast tillåter de bara manipulering av data av vissa enkla typer och definierar några enkla integritetsbegränsningar som åläggs dessa data. Mer komplex tolkning överlåts åt användaren. Det skulle dock vara bra om systemen kunde ha lite mer information och lite mer intelligent svar på användarförfrågningar, samt stödja mer komplexa (d.v.s. högre nivåer) användargränssnitt.

Idéerna med semantisk modellering kan vara användbara som ett databasdesignverktyg även om de inte direkt stöds i DBMS.

Den mest kända representanten för klassen av semantiska modeller är "entity-relationship"-modellen (ER-modellen) Metodiken för att bygga databaser är baserad på de teoretiska grunderna för deras design. För att förstå konceptet med metodiken presenterar vi dess huvudidéer i form av två successivt implementerade steg i praktiken:

Steg 1 - en undersökning av företagets alla funktionella divisioner för att:

Förstå detaljerna och strukturen för dess verksamhet;

Bygg ett diagram över informationsflöden:

Analysera det befintliga systemet;

Bestäm informationsobjekt och motsvarande sammansättning av detaljer (parametrar, egenskaper) som beskriver deras egenskaper och syfte.

2:a etappen - uppbyggnad av en konceptuell informationslogisk datamodell för det verksamhetsområde som undersökts i 1:a etappen. I denna modell måste alla kopplingar mellan objekt och deras detaljer upprättas och optimeras. Den informationslogiska modellen är grunden för att databasen ska skapas.

Entity-Relationship Model (ER-modell) (engelsk entity-relationship model (ERM) eller engelska entity-relationship diagram (ERD)) är en datamodell som gör det möjligt att beskriva konceptuella scheman. Ger en grafisk notation baserad på rutor och linjer som förbinder dem som kan användas för att beskriva objekt och relationer mellan dem i någon annan datamodell. I denna mening är ER-modellen en metadatamodell, det vill säga ett sätt att beskriva datamodeller.

Entitetsrelationsmodellen föreslogs 1976 av Peter Pin-Shen Chen, en amerikansk professor i datavetenskap vid Louisiana State University. Chen uppfann faktiskt inte modellen, han hämtade idéer från tidigare arbeten av utövare som A. Brown och andra. Men Peter Chen gjorde mer än någon annan före honom för att formalisera och popularisera ER-modellen, samt att introducera den i den vetenskapliga litteraturen.

På grund av synligheten av presentationen av konceptuella databasscheman har ER-modeller blivit utbredda i CASE-system som stödjer automatiserad design av relationsdatabaser. Bland de många notationerna av ER-modeller är en av de mest utvecklade Unified Modeling Language (Unified Modeling Language), förkortad. UML - används i ORACLE CASE-systemet. UML-notation används och/eller stöds också av: Borland Software Corporation, University of Bremen, University of Kent, University.

De viktigaste fördelarna med ER-modeller:

synlighet;

Modeller låter dig designa databaser med ett stort antal objekt och attribut;

ER-modeller implementerade i många system datorstödd design databaser (till exempel ERWin, Oracle Designer).

Huvudelementen i ER-modeller:

Objekt (entiteter);

Objektattribut;

Länkar mellan objekt.

En entitet är vilket domänobjekt som helst som har attribut.

Relationen mellan enheter kännetecknas av:

Typ av anslutning (1:1, 1:M, M:M);

Medlemsklass. En klass kan vara obligatorisk eller valfri. Om varje instans av en enhet deltar i en relation är medlemskapsklassen obligatorisk, annars är den valfri.

Konceptuell (infologisk) design - bygga en formaliserad modell av ämnesområdet. En sådan modell är byggd med hjälp av standardspråkverktyg, vanligtvis grafiska, såsom ER-diagram. En sådan modell är byggd utan att fokusera på något speciellt DBMS.

Huvuddelarna i denna modell:

1. Beskrivning av objekt i ämnesområdet och relationer mellan dem.

2. Beskrivning av användarnas informationsbehov (beskrivning av de viktigaste frågorna till databasen).

3. Beskrivning av arbetsflödet. Beskrivning av dokument som används som initialdata för databasen och dokument sammanställda på basis av databasen.

4. Beskrivning av algoritmiska beroenden mellan data.

5. Beskrivning av integritetsbegränsningar, dvs. krav på giltiga datavärden och relationer mellan dem.

Logisk (datalogisk) design är en kartläggning av en infologisk modell till en datamodell som används i en viss DBMS, till exempel till en relationsdatamodell. För relationell DBMS är en datalogisk modell en uppsättning tabeller, vanligtvis anger nyckelfält, relationer mellan tabeller. Om den infologiska modellen är uppbyggd i form av ER-diagram (eller andra formaliserade medel), så är datalogisk design konstruktion av tabeller enligt vissa formaliserade regler, samt normalisering av dessa tabeller. Detta steg kan till stor del automatiseras.

Fysisk design är implementeringen av en datalogisk modell med hjälp av en specifik DBMS, såväl som valet av lösningar relaterade till den fysiska datalagringsmiljön: valet av diskminneshanteringsmetoder, dataåtkomstmetoder, datakomprimeringsmetoder, etc. - dessa uppgifter löses huvudsakligen med hjälp av DBMS och är dolda för databasutvecklaren.

I stadiet av den infologiska designen, under insamlingen av information om ämnesområdet, är det nödvändigt att ta reda på:

1. ämnesområdets huvudobjekt (objekt om vilka information bör lagras i databasen);

2. attribut för objekt;

3. länkar mellan objekt;

4. grundläggande frågor till databasen.

Normalform är en egenskap hos en relation i en relationsdatamodell som kännetecknar den i termer av redundans, vilket potentiellt kan leda till logiskt felaktiga resultat av sampling eller ändring av data. Normalformen definieras som den uppsättning krav som en relation måste uppfylla.

Processen att konvertera en databas till en form som överensstämmer med normala former kallas normalisering. Normalisering är avsedd att föra strukturen av databasen till en form som ger minimal redundans, det vill säga normalisering är inte avsedd att minska eller öka prestanda, eller minska eller öka storleken på databasen. Det slutliga målet med normalisering är att minska den potentiella inkonsekvensen av information som lagras i databasen.

Elimineringen av redundans görs som regel genom att sönderdela relationer på ett sådant sätt att endast primärfakta lagras i varje relation (det vill säga fakta som inte härrör från andra lagrade fakta).

Avsnitt 1 Slutsatser

I avsnitt 1 övervägdes informationssystem och information, databehandlingsmetoder, grundläggande databehandlingskoncept (begreppet filsystem, begreppet databaser, begreppet objektivt orienterade databaser), huvudfunktionerna i ett DBMS. Datamodeller beaktas: nätverk, hierarkiska, relationella. Den relationella datamodellen beskrevs i detalj.

Användningen av informationssystem bidrar till en effektivare lösning av ledningsproblem baserat på ett snabbt tillhandahållande av hela informationen som ligger till grund för beslutsfattande. Utformningen och konstruktionen av ett informationssystem bör baseras på en omfattande analys av ämnesområdet. Det finns olika metoder för att beskriva ämnesområdet, bland vilka vi pekade ut ett objektorienterat tillvägagångssätt för modellering, eftersom det ger den bästa implementeringen av ett informationssystems dynamiska beteende.

Det här avsnittet identifierar problemet och förklarar hur det kan lösas på ett generellt sätt. För att ge praktiska rekommendationer måste du följa följande steg:

Välj en konceptuell modell med vilken det konceptuella schemat ska byggas;

Skapa en korrekt beskrivning av de semantiska begränsningarna som stöds av det valda DBMS;

Bygg en kartläggning av den valda konceptuella modellen till datamodellen som stöds av DBMS.

Definiera vad en bra krets är och beskriv hur den är uppbyggd.

Information om arbetet "Design, utveckling och implementering av IS-databasen i företagets ekonomiska verksamhet (i exemplet SE "Alushtalift")"

Kort om det viktiga.

Databasnormalisering

Första normalformen (1NF)

• inga dubbletter av datagrupper
• garanterad elementaritet (atomicitet) av data (alla data är autonoma och oberoende).

På översta nivån uppnås detta genom att skapa en primärnyckel, sedan migrera upprepade grupper av data till nya tabeller, skapa primärnycklar för dessa tabeller och så vidare. Dessutom måste du bryta alla poster vars kolumner innehåller sammansatt information i separata rader för varje del av kolumndata.

Andra normala formen (2NF)

• tabellen uppfyller villkoren för 1NF
• varje kolumn beror på hela nyckeln, inte en del av den.

Tredje normalformen (3NF)

• tabellen uppfyller villkoren för 2NF
• ingen kolumn beror på en kolumn som inte är en del av primärnyckeln
• innehåller inte härledd data

Andra normala former av ringa praktiskt värde:

Boyce-Codd normalform

Variant 3NF. Designad för att lösa situationen med närvaron av många överlappande kandidatnycklar. I själva verket finner den inte någon logisk motivering utanför det akademiska samfundet.

fjärde normalformen

Designad för att lösa ett problem med flervärdiga beroenden. Sådana situationer uppstår om, i en tabell reducerad till 3NF, en kolumn i den sammansatta primärnyckeln beror på en annan kolumn i primärnyckeln.

Femte normalformen

Det används när man arbetar med nedbrytning av relationer med förluster och utan förluster. Uppstår i en situation där en relation kan brytas upp i flera olika relationer, men efter det kan vi inte längre logiskt återställa den till sin ursprungliga form.

Sjätte normalformen (normalform för domännyckel)

Säkerställer att det inte finns några modifieringsavvikelser i databasen. Under verkliga förhållanden är det praktiskt taget inte möjligt.

Relationer.

En gång hörde jag från kvinnor att män
omedelbart försöka lämna rummet där
ordet "förhållande" användes.<...>nyckel till framgång
relation är allas medvetenhet om sin roll
i detta avseende, liksom reglerna och begränsningarna
påtvingad av detta förhållande.
(C) Robert Viera, "Professionell SQL Server 2000-programmering"

Typer av relationer

• En-till-en (användbart när du behöver lagra samma data i olika databaser eller när den maximala raddatastorleken överskrids)
• Noll-eller en-till-en
• En till många
• En till -noll, -en eller -många
• Många-till-många (länktabeller)

Föreningar

INRE KOPPLING

Exklusiv anslutning (exklusiv anslutning). Urvalsresultatet inkluderar endast de poster av tabeller som har matchningar i den parade tabellen enligt det angivna villkoret.

VÄNSTER|HÖGER GÅ MED

En inkluderande anslutning. Resultatet av urvalet inkluderar poster från tabellen till vänster/höger om ANSLUTA SIG respektive. I det här fallet kommer data från den saknade "par"-posten att fyllas i NULL.
FROM left_table LEFT JOIN right_table– inkluderade alla poster från den vänstra tabellen left_table
FROM left_table RIGHT JOIN right_table– inkluderade alla poster från den högra tabellen right_table

FULL GÅ MED

En inkluderande anslutning. Urvalsresultatet inkluderar inte bara poster som har en matchning i den andra tabellen, utan även poster från båda tabellerna för vilka ingen matchning hittades i den andra tabellen. I det här fallet kommer data från den saknade "par"-posten att fyllas med NULL.

KORS-GÅ MED

Cross union (kartesisk produkt). Varje post från en tabell mappas till varje post från en annan tabell. Antalet resulterande poster är lika med produkten av antalet poster i båda tabellerna.

Flera beställningsprinciper ANSLUTA SIG s

Om du behöver gå med i flera bord måste du komma ihåg två principer:

1. Alla fack till vänster ANSLUTA SIG behandlas som en enda tabell som ska inkluderas eller exkluderas från frågan.
2. Alla föreningar RÄTT ANSLUTA SIGÄVEN behandlas som en enda tabell för att inkludera eller exkludera från en fråga.

En följd av dessa principer är följande rekommendation för att bilda komplexa sammanfogningar:

• När det är möjligt ska INNER JOIN användas.
• Om det finns behov av att använda OUTTER JOIN ska de placeras sist och INNER JOIN placeras i början av föreningen.

P.S. Allt ovanstående är allmänna "postulat" av teorin om relationsdatabaser, inte bundna till funktionerna i vissa DBMS.

En databas (DB) är en organiserad samling av data. Organiseringen av uppgifter är vanligtvis avsedd att återspegla det verkliga förhållandet mellan de lagrade uppgifterna på ett sådant sätt att det underlättar behandlingen av denna information.

DBMS - databashanteringssystem - är en specialiserad programvara designad, förväntas, för att hantera databaser. Detta uppnås genom interaktion med användaren å ena sidan och med själva databasen å andra sidan.

DBMS generell mening bör möjliggöra definition, skapande, modifiering, administration och produktion av frågor till databasen.

Exempel på DBMS inkluderar sådana välkända paket som

• MySQL
• PostgreSQL
• Microsoft SQL Server
• Orakel
• IBM DB2
• Microsoft Access
• SQLite

Databaser är vanligtvis inte portabla mellan olika DBMS, men interoperabilitet mellan DBMS (och med användarprogram) är möjlig med hjälp av olika standarder som SQL, ODBC eller JDBC.

RDBMS klassificeras ofta enligt den datamodell de stöder. Sedan 1980-talet har nästan alla populära DBMS:er stödt den relationsdatamodell som representeras av SQL-frågespråksstandarden (även om NoSQL har blivit populärt de senaste åren).

Så, de viktigaste uppgifterna som utförs av DBMS inkluderar

Definiera dataschemat Skapa, ändra och ta bort strukturer som definierar organisationen av all annan data i databasen. Ändra data Lägga till, ändra och ta bort själva data Hämta data Tillhandahålla information i en form som direkt kan användas av andra applikationer. Databasadministration Användarregistrering och -hantering, datasäkerhet, integritetsunderhåll, informationsåterställning, samtidighetskontroll, prestandaövervakning m.m.

DBMS används i stor utsträckning inom banker, transportföretag, utbildningsinstitutioner, telekommunikation, finansiell informationshantering och mänskliga resurser. Tja, glöm inte att de flesta av webbens backends använder ett eller annat DBMS.

En av huvuddragen i databasutveckling är det faktum att det inte finns några färdiga lösningar och algoritmer. Varje databas är specifik för den uppgift den är designad för. Detta skiljer databasutveckling från utveckling av typiska applikationer för vilka algoritmer och designmönster har utvecklats under lång tid och man inte behöver uppfinna något speciellt. Även om, naturligtvis, databasdesigntekniker är gemensamma för alla applikationer.

DB-modeller

Som tidigare nämnts är den mest använda datamodellen relationsmodellen. Framträdandet av relationsmodellen föregicks dock av framför allt andra

• Hierarkisk eller navigeringsmodell
• nätverksmodell

Den hierarkiska modellen användes flitigt i DBMS som tillhandahölls av IBM på 1960-talet. Huvudtanken är att en post i en sådan databas kan ha flera "barn" och en "förälder". Sammantaget ser det misstänkt ut som ett hierarkiskt filsystem. För att få en post i en sådan databas är det ofta nödvändigt att gå igenom hela trädet.

Nätverksmodellen är en mer flexibel version av samma tillvägagångssätt. Det låter dig ha flera "förälder"-poster. Denna modell, som dök upp i början av 1970-talet, användes inte i stor utsträckning, och ersattes snart av den relationella modellen.

På 1970-talet föreslog Edgar Codd (en IBM-anställd) en relationsmodell som i hög grad underlättade uppgiften att hitta information i en databas. Du kan tänka på relationsmodellen som "tabeller" där "raderna" är posterna i databasen. Poster i en relationsdatabas kallas också tupler, och grupper av poster ("tabeller") kallas relationer. Relationsmodellen kan uttrycka relationerna mellan hierarkiska modeller och nätverksmodeller och har lagt till egna relationer som motsvarar tabellmodellen.

Baserat på Codds förslag utvecklades System R DBMS i mitten av 1970-talet, och mot slutet hade det stöd för det standardiserade SQL-frågespråket.

På 1980-talet, med tillkomsten av objektorienterad programmering, blev det allt svårare att översätta objekt till en relationsmodell. I slutändan ledde detta till uppkomsten av NoSQL- och NewSQL-metoder, som för närvarande bara utvecklas. Exempel på implementering av NoSQL-metoden kan vara den så kallade. dokumentorienterade databaser byggda på basis av XML. Den största fördelen med NoSQL är dess höga horisontella skalbarhet, d.v.s. möjligheten att öka prestandan genom att lägga till servrar. Med tillkomsten av cloud computing har NoSQL blivit särskilt efterfrågat.

Ändå är relationsmodellen fortfarande den vanligaste, så vi kommer att uppehålla oss mer i detalj.

relationsmodell

Relationsmodellen fungerar i termer av poster, attribut och relationer. Relationen kan ses som en tvådimensionell tabell, då är attributen tabellens kolumner (mer exakt namnen på kolumnerna), och posterna är tabellens rader.

Relationsmodellen kräver en strikt definition av datastrukturen som lagras i databasen, det vill säga relationerna och attributen för denna databas är fixerade.

Låt oss presentera några definitioner.

Domän En uppsättning som innehåller den kompletta uppsättningen av alla möjliga värden för någon variabel. Domäner kallas ofta data typ. Beställt par-attribut attributnamn och domänen \(D_j\) . Tuple Finite ordnad uppsättning \((d_1, d_2, \ldots, d_n)\) Relationshuvud (schema) Tuple \((A_1, A_2, \ldots, A_n)\) , där \(A_j\) är attribut. Attributvärde Ett specifikt värde som hör till attributets domän. Relationskropp En uppsättning tupler, där \(d^i_j \in D_j\) , \(D_j\) är domäner. Spela in Tuple \((d^i_1, d^i_2, \ldots, d^i_n)\) för fast \(i\) . Relation Kombinationen av relationshuvudet och relationskroppen. Databasschema Uppsättningen av scheman för alla relationer som ingår i databasen.

Du kan representera relationen i form av en tabell. Då är relationskroppen tabellens kropp, relationens huvud är tabellens huvud, attributen är namnen på kolumnerna, posterna är raderna och värdena för attributen finns i cellerna:

\(A_1\)	\(A_2\)	\(\ldots\)	\(En\)	← Titel
\(d^1_1\)	\(d^1_2\)	\(\ldots\)	\(d^1_n\)	← Inspelning
\(d^2_1\)	\(d^2_2\)	\(\ldots\)	\(d^2_n\)	← Inspelning
\(\ldots\)	\(\ldots\)	\(\ldots\)	\(\ldots\)	← Inspelning
\(d^m_1\)	\(d^m_2\)	\(\ldots\)	\(d^m_n\)	← Inspelning

Relationsmodellen ställer följande ytterligare krav på relationer:

Det är tydligt att attributen (mer exakt, deras värden) på något sätt beror på varandra - annars visar sig relationen bara vara en ostrukturerad datamängd. För att bestämma beroenden mellan attribut används begreppet funktionellt beroende.

Funktionellt beroende En attributuppsättning \(B\) är funktionellt beroende av en attributuppsättning \(A\) (skriven \(A\högerpil B\) ) om för två poster som har samma värde \(A\), deras värden \(B\) matchar. Annars motsvarar varje värde \(A\) ett enda värde \(B\) (inte nödvändigtvis unikt, bara unikt).

Med andra ord, om någon uppsättning attribut \(A\) unikt bestämmer (inom den givna relationen) värdena för attributen \(B\) , då är \(B\) funktionellt beroende av \(A\) .

Som ett mer välbekant exempel på funktionellt beroende kan vi nämna den matematiska definitionen av en funktion. För en funktion motsvarar varje argumentvärde ett enda funktionsvärde. Det omvända är i allmänhet inte sant, till exempel för funktionen \(y = sin(x)\) motsvarar vilket värde \(y\) som helst från domänen \(1\geq y \geq -1\) en oändlig mängd av värden \(x\ ), men för varje värde \(x\) finns det exakt ett värde \(y\) , så \(x \till y\) . Observera att begreppet funktionellt beroende också är tillämpligt på funktioner av många variabler. För dem är värdet av funktionen funktionellt beroende av alla argument samtidigt. Låt oss säga att för funktionen \(z = f(x,y)\) är FZ \((x,y)\to z\) , eller \(xy\to z\) för kort, uppfyllt.

Relationer i detta sammanhang kan ses som tabell eller diskreta funktioner.

Arbetar med federal lag

Det finns vissa formella regler för att arbeta med FZ-relationer.

Formella regler är nära besläktade med begreppen stängningar och oreducerbar federal lag.

Armstrongs axiom

Det finns regler för härledning av nya federala lagar från befintliga, kallade Armstrongs axiom.

Armstrongs axiom

1. Reflexivitetsregel: om \(B \delmängd A\) , då \(A\högerpil B\)
2. Komplementregel: om \(A\högerpil B\) sedan \(AC\högerpil BC\)
3. Transitivitetsregel: om \(A\högerpil B\) och \(B\högerpil C\) , då \(A\högerpil C\)

Från dessa axiom kan följande ytterligare regler också härledas:

1. Självbestämmanderegel: \(A\högerpil A\)
2. Nedbrytningsregel: Om \(A\högerpil BC\) , då \(A\högerpil B\) och \(A\högerpil C\)
3. Unionsregel: Om \(A\högerpil B\) och \(A\högerpil C\) då \(A\högerpil BC\)
4. Kompositionsregel: Om \(A\högerpil B\) och \(C\högerpil D\) , då \(AC\högerpil BD\)

Det kan ses att, på grund av reflexivitetsregeln, innebär varje uppsättning attribut \(A\) en FD av formen \(A\till A\) . Sådana FDs, såväl som de följande, är inte av intresse och kallas triviala.

Trivialt funktionellt beroende av FZ \(A \till B\) så att \(B \subset A\) .

Dessa regler är i princip tillräckliga för att hitta alla FD:er som följer av uppgifterna. I detta avseende introduceras begreppet stängning av en uppsättning FD.

Stängning av en uppsättning FD:er En stängning av en uppsättning FD:er är en sådan uppsättning FD:er som inkluderar alla FD:er i den ursprungliga uppsättningen, såväl som alla FD:er som antyds av dem. Med andra ord, för en relation \(R\) som har funktionella beroenden\(S\) , stängningen \(S^+\) är uppsättningen av alla FD:er som är möjliga för \(R\) , baserat på \(S\) .

Som regel krävs det att fastställa om en viss FL \(X\högerpil Y\) kommer att följa ifrån given uppsättning FZ \(S\) . Det visar sig att detta är möjligt om och endast om attributuppsättningen \(Y\) är en delmängd av attributstängningen \(X^+\) i \(S\) .

Stängning av attribut Stängningen \(X^+\) av attribut \(X\) med avseende på uppsättningen FDs \(S\) är uppsättningen av alla attribut som är funktionellt beroende av någon delmängd \(X\) .

För att beräkna stängningen av attributuppsättningen \(X^+\) med avseende på FD \(S\)-uppsättningen, finns följande regel: för varje FD \(A\högerpil B\) i \(S\) , om \(A \subset X^ +\) , så är \(B \subset X^+\) det också, och det räcker med att börja med antagandet att \(X^+ = X\) .

Det bör noteras att för varje stängning \(X^+\) , finns det FDs av formen \(X \till B\) , där \(B \subset X^+\) , alltså stängningarna av alla relationer attribut av dess FD beskriver stängningen av FZ för denna relation.

Denna regel används för att beräkna en irreducerbar uppsättning av FD som är likvärdig med den givna (i betydelsen av likvärdigheten mellan deras stängningar). Att minska antalet FD:er samtidigt som stängningen bibehålls (och därför den interna logiken som beskrivs av FD) är ett viktigt steg i databasdesign.

En uppsättning FD:er kallas irreducible om:

1. Den högra sidan av varje FL innehåller bara ett element
2. Inget av attributen för någon vänstra del av FZ på setet kan tas bort utan att ändra stängningen
3. Ingen av de inställda FD:erna kan tas bort utan att ändra förslutningen.

För varje uppsättning av FD:er finns det minst en likvärdig irreducerbar uppsättning. En sådan uppsättning kallas minimal täckning.

Innan vi tittar på vart och ett av dessa steg i detalj, låt oss titta på de grundläggande begreppen för relationsdatabaser. I relationsteorin är ett av huvudbegreppen begreppet relation. Matematiskt definieras förhållandet enligt följande. Låt n mängder D1,D2,...,Dn ges. Då är R en relation över dessa mängder om R är en uppsättning ordnade samlingar av formen< d1,d2,...,dn>, där d1 är ett element från D1, d2 är ett element från D2, ..., dn är ett element från Dn. I det här fallet, uppsättningar av formuläret kallas tupler, och mängderna D1,D2,...,Dn kallas domäner. Varje tupel består av element valda från sina domäner. Dessa element kallas attribut, och deras värden kallas attributvärden, vilket ger oss en grafisk representation av förhållandet från olika synvinklar.

Ris.

Det är lätt att se att relationen är en återspegling av någon enhet i den verkliga världen (i detta fall entiteten "detalj") och, ur databehandlingssynpunkt, är en tabell. Eftersom i lokala databaser varje tabell finns i en separat fil, ur dataplaceringssynpunkt för lokala databaser, kan relationen identifieras med en fil. En tuppel är en rad i en tabell, eller motsvarande en post. Ett attribut är en tabellkolumn eller ett fält i en post. En domän, å andra sidan, representeras av en generisk typ som kan vara en källa för fälttyper i en post. Följande termtripletter är alltså ekvivalenta:

• relation, tabell, fil (för lokala databaser)
• tupel, sträng, skiva
• attribut, kolumn, fält.

Relationsdatabasär en uppsättning relationer som innehåller all nödvändig information och förenas av olika länkar.

Ett attribut (eller en uppsättning attribut) som kan användas för att unikt identifiera en viss tupel (sträng, post) kallas primärnyckel. Primärnyckeln får inte ha ytterligare attribut. Detta innebär att om ett godtyckligt attribut utesluts från primärnyckeln, kommer de återstående attributen inte att räcka för att unikt identifiera individuella tupler. För att påskynda primärnyckelåtkomsten har alla databashanteringssystem (DBMS) en mekanism som kallas indexering. Grovt sett är ett index en postningsträdlista som pekar på den sanna platsen för posten för varje primärnyckel. Naturligtvis implementeras index olika i olika DBMS (i lokala DBMS, som regel, i formen enskilda filer), men principerna för deras organisation är desamma.

Det är möjligt att indexera en relation med andra attribut än primärnyckeln. Den här typen index kallas sekundärt index och används för att minska åtkomsttiden vid hitta data i relation, samt för sortering. Således, om själva relationen inte är ordnad på något sätt och den kan innehålla rader kvar efter borttagningen av några tupler, så sorteras indexet (för lokal DBMS - en indexfil), tvärtom.

För att upprätthålla referensintegritet för data har många DBMS en mekanism av sk främmande nycklar. Innebörden av denna mekanism är att något attribut (eller grupp av attribut) för en relation tilldelas en referens till primärnyckeln för en annan relation; sålunda är underordningsbanden mellan dessa relationer fasta. En relation vars primärnyckel refereras av den främmande nyckeln för en annan relation anropas mästarrelation, eller huvudrelation; och relationen från vilken länken kommer kallas detaljförhållande, eller en underordnad relation. Efter att ha tilldelats en sådan länk har DBMS förmågan att automatiskt spåra frågor om "icke-kränkning" av länkar mellan relationer, nämligen:

• · om du försöker infoga en post i den underordnade tabellen för vilken den främmande nyckeln inte har en matchning i huvudtabellen (det finns till exempel ingen post med samma primärnyckel), kommer DBMS att generera ett fel;
• · Om du försöker ta bort en post från huvudtabellen, vars primärnyckel har minst en länk från den underordnade tabellen, kommer DBMS också att generera ett fel.
• · Om du försöker ändra primärnyckeln för en huvudtabellpost som har minst en länk från den underordnade tabellen, kommer DBMS också att generera ett fel.

Kommentar . Det finns två sätt att ta bort och ändra poster från huvudtabellen:

• 1. Förbjud radering av alla poster, samt ändring av primärnycklarna i huvudtabellen, som det finns länkar till i den underordnade tabellen.
• 2. Sprid alla ändringar i primärnyckeln i huvudtabellen till den underordnade tabellen, nämligen:
  • o om en post raderas i huvudtabellen, måste alla poster som hänvisar till den som raderas tas bort i den underordnade tabellen;
  • o om primärnyckeln för en post ändras i huvudtabellen, måste alla främmande nycklar för posterna som hänvisar till den tabell som ändras ändras i den underordnade tabellen.

Så, efter att vi har blivit bekanta med de grundläggande begreppen för relationsteori, kan vi gå vidare till en detaljerad övervägande av databasdesignstegen som vi har listat ovan.

relationsindexering av databaser