Data förknippas vanligtvis med programmering och presenteras i den moderna informationsvärlden i tre logiskt likvärdiga versioner: data som beskrivs och används i ett program på ett programmeringsspråk; data i databassystem; data i distribuerade informationssystem. Modern programmering har endast givit relativ frihet till den första varianten av informationsformalisering. De två andra alternativen är mer eller mindre tillförlitliga former för att tillhandahålla information och relationer mellan dess komponenter.
Data tidigare och nutid
Programmeringsspråkens grundläggande position är den exakta beskrivningen av data och algoritmer. Datorer "presenterar" inte någon chans till osäkerhet: det finns något att agera på, och det finns ett kommando som utför den åtgärden.
Det moderna konceptet bygger på en mycket högre grund: det finns ett givet och exakt vad det kommer att vara bestäms på platsen för dess användning. I vilket fall som helst, vid användningstillfället, kontrolleras uppgifterna automatiskt och konverteras till rätt typ. En modern programmerare är inte skyldig att ta hand om sin preliminära beskrivning och iakttagande av typkompatibilitet i algoritmen.
Övergångsprocess:
- från inskriven data och dess obligatoriska beskrivning före användning;
- till oskrivna data och frihet från skyldigheter att beskriva och använda dem.
Vi kan faktiskt känna igen den relativa lättnaden av formaliseringskraven - den är endast tillgänglig i miljön med moderna programmeringsverktyg. Vid körning är typen av varje datum fast, och kommandosekvensen är väldefinierad.
Typer och modellering
Matematik och fysik, handel och produktion, ekonomi och andra områden där siffror används, har alltid arbetat med data och har inte fäst någon vikt vid typbegreppet. Att tal kunde vara hela eller bråkdelar spelade ingen roll.
Varje specifik formel eller specifik åtgärd kan ge ett heltal, oändligt bråktal, reellt eller komplext tal. Fram till nu finns det sinnets underverk som oändligt små och oändligt stora. Dessutom har dessa mirakel till och med egenskaper.
Det finns fortfarande ingen frihet i programmering. Allt måste vara strikt formaliserat. Begreppet data är först och främst en typ:
- integer;
- boolean;
- char;
- sträng och så vidare.
Namn på typer kan skilja sig åt i olika programmeringsspråk, men det finns alltid ett heltal eller ett reellt tal, booleskt värde, symbol,linje. Det finns fortfarande reliker och specifika idéer kvar: heltal utan tecken, kod, byte, ord, dubbelord, sträng med fast längd.
Begreppet data i ett datasystem har ingen frihet. SQL-språket - "internationellt" (det finns en dialekt för varje modern databas) - tolererar inte några felaktigheter, inte bara i data, utan även i sql-frågor. Ett fel i begäran är en garanti för frånvaron av ett resultat. Det finns inget behov av att prata om överträdelser av beskrivningar alls.
Modellering av informationsprocesser och datarepresentationer är det enda säkra sättet att bygga en struktur som kan utvecklas och anpassas till förändrade förhållanden.
Dynamics of original
Naturlig information förändras kontinuerligt. Att ge en formell beskrivning och koncept för en datamodell inom ett specifikt ämnesområde innebär att lösa tre problem:
- definiera vilken data som finns här;
- formalisera relationen mellan dem;
- beskriv processer för att ändra data och relationer.
Ett exempel på en datamängd av en enkel algoritm i JavaScript - en reducerad kopia av modellen för även det mest solida databashanteringssystemet.
Det är bara det att i det andra fallet ser experter och specialister, när de utformar datastrukturer, tabeller och relationer, vanligtvis inte (det är verkligen svårt att täcka en stor mängd naturlig information) essensen av saker, och en besvärlig, outvecklad mängd data erhålls, medan källinformationen inom ämnesområdet cirkulerar fritt och enkelt.
Statiskmöjligt
Det är vanligt med JavaScript att inkludera kod kopplad till en sida och funktioner som tilldelats händelser i sidtaggar. Hur som helst, sidtaggar definierar data som en given webbresurs accepterar, modifierar eller skapar.
Om du koncentrerar din hanterarkod mycket noggrant på elementhändelser, och inte på sidkoden som helhet, är detta den bästa vägen ut. Helst när koden inte introducerar ny data eller inte fixar tillgänglig data, utan fokuserar på exakt vad den har vid en viss tidpunkt.
Faktum är att om du definierar begreppet "data" som en minim alt statisk beskrivning av källinformationen och följer den, betyder det att du har en chans att lyckas.
När det gäller databaser är saker och ting mycket mer komplicerade. Alla JavaScript-koder "förser" sidan med funktionalitet. Vilken databas som helst är en samling tabeller, relationer mellan dem, lagrade procedurer, frågor och funktionalitet som är tillgänglig utifrån.
Statisk är besväret med vilken algoritm som helst. Det moderna begreppet data är statiskt: ett tal, en sträng, ett tecken och så vidare. När man bearbetar eller skriver till en databastabell går allt smidigt. Men när får originalet en annan dimension eller betydelse? Alternativ ett: ändra skylten, men anslutningar och förfrågningar kan falla in omedelbart.
Statik och objekt
Att definiera begreppet "data" som ett objekt förändrar situationen dramatiskt. Objektet har sin egen struktur. Här kan du använda valfri beskrivning av alla variabler. Roll kommer inte att spelas. Ett objekt har metoder genom vilka data är tillgänglig. Sedan alltanvänds inom programmeringsområdet, det vill säga tre grundläggande metoder: läsa, skriva, ändra. Du kan lägga till fler för att jämföra, söka, klona, etc.
Ämnesområdet lägger en rad egenskaper på varje data. Därmed visar det sig att begreppet data omvandlas till en slags beskrivning som kan förändras dynamiskt. Statisk inuti ett objekt ger dynamik utanför det.
Om du ändrar kombinationen av statiska deskriptorer inuti ett objekt behöver du inte oroa dig för dynamiken i dess relationer med andra objekt.
Programmering och presentation av data
Vad är data? Det allmänna medvetandet är redan vant vid informationsteknik, arbetar i molnen och har behållare i virtuella utrymmen. Nu är inte bara professionella programmerare och användare, utan även vanliga människor kompetenta i frågor om information och dess användning.
Men vad är programmering? Än i dag ger den allmänna opinionen följande definition av detta begrepp och dess begrepp:
- Information och data är de grundläggande begreppen som används inom datavetenskap.
- Data är ett visst sätt mottagna och registrerade observationer i förhållande till den omgivande verkligheten.
- De är enkla och komplexa (strukturer), primära och sekundära.
- En databas är en samling oberoende material som presenteras på ett systematiskt sätt så att de kan hittas, modifieras och användas.
Hur objektivt är detta? Auktoritativa författaretror det. Verklig praxis tenderar att säkerställa att varje ämnesområde bestämmer sitt korrekta datasystem och ger alla möjligheter att bygga en bra dynamisk modell.
Det är inte ovanligt att en kund (konsument) påtvingar en programmerare (databasdesigner) sin egen åsikt om hur och vad man ska göra. Ur programmeringssynpunkt kan kundens önskemål uppfyllas med yttersta precision.
Behöver Oracle för att lösa problemet med budgetering för underhåll av landsbygdens vattenförsörjning (byggnad 21 i byn) - bra. MySQL behövs för att organisera ett spårningssystem för postförsändelser för alla postkontor i Ryssland - allt kommer att fungera också.
Du kan alltid komponera vilken algoritm som helst och ge tillgång till vilken representation av information som helst inom definitionen av begreppet data, som fastställts av utvecklaren av databashanteringssystemet eller programmeringsspråket. Frågan är en annan: hur gör man det med minimala kostnader i maximal dynamik?
Databaser, exempel
En enkel bas skapas utan modell. De grundläggande begreppen data och kommunikation är små, funktionaliteten är mycket enkel. Till exempel, för en högre utbildningsinstitution behöver du:
- lärartabell;
- grupptabell (nyckel och gruppnummer);
- allmän tabell över elever (gruppnycklar används).
Dekanus vill veta lärarnas framsteg. Lärartabellen har fält:
- efternamn;
- namn;
- patronymic;
- övervakat gruppnummer.
Elevtabellen har fält:
- efternamn;
- namn;
- patronymic;
- födelsedatum;
- GPA (för alla ämnen);
- gruppnummer.
Det kan finnas minst två alternativ för provtagning: med hjälp av lärarens namn kan du gå till gruppnumret och se alla elever och deras medelpoäng, eller genom lärarens efternamn och den sista elevens namn, du kan se medelpoängen för den senaste.
Även i en så enkel version garanteras problem och något måste ändras. Situation: läraren blev sjuk, ytterligare en månad ersätter honom, vilket innebär att han övervakar två grupper. Det finns bara ett fält under ett gruppnummer i lärartabellen.
För att lösa problemet måste du lägga till ett dubblettfält. Och om två blir sjuka, lägg till tre fält. Så lärartabellen börjar växa från grunden.
Det finns ett annat alternativ: ersätt det numeriska fältet för gruppnyckeln med ett symboliskt. Sedan, varje gång du väljer, måste du konvertera strängen till en sekvens av nycklar, och en sql-fråga kommer att förvandlas till flera.
Ett mer lovande exempel är inte att göra tabeller, utan att göra objekt. Då är läraren ett objekt, och han kan ha flera övervakade grupper. Men det är alltid ett objekt. Lärarobjektet har en unik nyckel, men kan ha flera övervakade grupper. Gruppen har också en unik nyckel. En student också.
Alla tre positionerna är inte bara tillgängliga inom uppgiften, utan kan vidareutvecklas.
Objektorienterade baser
ledare inom informationsbranschenerbjuda klassiska relationsdatabaser. De testas av livet, de fungerar, de är säkra, pålitliga och, i händelse av problem, låter de dig återställa information.
Objektorienterade databaser (OODB) började utvecklas i mitten av 1980-talet och är, enligt auktoritativa författare, lovande än i dag. Men än så länge, förutom grundläggande teorier och konceptuella bestämmelser, finns det ingen OODB som har uppnått samma betyg och distribution som MySQL, MS SQL Server eller Oracle i alla dess olika inkarnationer.
Men vad händer om definitionen, begreppet data, typer, attribut, klasser, hierarkier föreslås av en utvecklare vars betyg är otillräckligt för att skapa en gemenskap av programmerare som bekänner sig till mentaliteten hos denna OODB? Vi måste lita på vår egen styrka.
Fler än trettio varianter av OODB har skapats i Linux-miljön. Men var är garantin att den skapade databasen inte kommer att kräva mer funktionalitet? Windows-miljön erbjuder inte mycket garantier på detta område.
Objektorienterad lösning
Det finns dock en lösning. Med MySQL som exempel kan du visa hur standardrelationstabeller förvandlas till en objektorienterad modell av problemet som löses.
Det finns ingen databas här, men det finns en miljö för att skapa ett eget system av objekt. Kraften i MySQL används endast som relationsminne för tabeller från inforader. Användningslogiken bestäms av utvecklaren själv. I synnerhet finns det en is_cache-tabell. Den har alltflera grundläggande fält:
- owner_code;
- session_code;
- h_code;
- a_surprise;
- a_contents.
Resten av fälten innehåller servicefunktioner. Denna tabell står vid ingången av varje begäran och registrerar dess ankomst. Vad databasmodellen kommer att fungera bestäms av dess utvecklare. Vad som får plats i innehållsfältet (a_contents) bestäms av objekten i modellen som skapats av utvecklaren.
Det finns fyra saker i den här idén: träff, träffsession, träffhistorikkod och specifikt innehåll. Vad är ett samtal, vilket system av objekt som ska byggas - bestäms av utvecklaren. Vad som menas med en session (arbetsprocess) bestäms av utvecklaren. Historikkoden är möjligheten att återställa förfrågningar.
Tabellerna här har inget med ämnesområdet att göra. Det finns en samtalskontroller (is_cache), det finns loggning (is_customs), det finns en samtalshistorik (is_histories). De återstående tabellerna bestäms av uppgiften som löses.
Faktum är att den här lösningen föreslår att du skapar din egen OODB baserat på den inbyggda domändatabasmodellen och problemet som löses. Det finns ett stort plus här - det här är ditt eget koncept av data, din egen modell av deras presentation och relationen mellan dem. Det finns en grund här - en stor relationsdatabas. Det blir inga problem att leta efter något och missförstå något.
Modell: objektsystem + DBMS
Det är nästan omöjligt att ändra någonting inom informationsteknologin. Den verkliga informationsrevolutionen är fortfarande långt borta. professionellt medvetandemjukvaruutvecklare kommer inte att förändra de klassiska traditionerna. Men det finns fortfarande en väg ut ur situationen.
Genom att använda pålitliga moderna databashanteringssystem som grund för att skapa en miljö för existensen av din egen modell, kan du nå märkbara framgångar.
I vilket fall som helst måste du bygga en vy eller en datamodell för att lösa uppgiften, men du måste göra det korrekt: låt det vara ett system av objekt och ett bra DBMS vara dess miljö.
