Data er norm alt forbundet med programmering og præsenteres i den moderne informationsverden i tre logisk ækvivalente versioner: data beskrevet og brugt i et program i et programmeringssprog; data i databasesystemer; data i distribuerede informationssystemer. Moderne programmering har kun givet relativ frihed til den første variant af informationsformalisering. De to andre muligheder er mere eller mindre pålidelige former for at give information og relationer mellem dets komponenter.
Data fortid og nutid
Den grundlæggende position for programmeringssprog er den nøjagtige beskrivelse af data og algoritmer. Computere "præsenterer" ikke nogen chance for usikkerhed: der er noget, der skal handles på, og der er en kommando, der udfører den handling.
Det moderne koncept er baseret på et meget højere grundlag: der er et givet, og hvad det præcist vil være, bestemmes på stedet for dets brug. Under alle omstændigheder, på tidspunktet for brug, kontrolleres dataene automatisk og konverteres til den korrekte type. En moderne programmør er ikke forpligtet til at tage sig af deres foreløbige beskrivelse og overholdelse af typekompatibilitet i algoritmen.
Overgangsproces:
- fra indtastede data og dets obligatoriske beskrivelse før brug;
- til uskrevne data og frihed fra enhver forpligtelse til at beskrive og bruge dem.
Faktisk kan vi genkende den relative lempelse af formaliseringskrav - den er kun tilgængelig i miljøet med moderne programmeringsværktøjer. Ved kørsel er typen af hvert datum fast, og kommandosekvensen er veldefineret.
Typer og modellering
Matematik og fysik, handel og produktion, økonomi og andre områder, hvor tal bruges, har altid opereret med data og har ikke tillagt begrebet type nogen betydning. Det faktum, at tal kunne være hele eller brøkdele, var ligegyldigt.
Hver specifik formel eller specifik handling kunne give et heltal, uendelig brøk, reelt eller komplekst tal. Indtil nu er der sådanne vidundere i sindet som uendeligt små og uendelige store. Desuden har disse mirakler endda egenskaber.
Der er stadig ingen frihed i programmering. Alt skal være strengt formaliseret. Begrebet data er først og fremmest en type:
- heltal;
- boolean;
- char;
- streng og så videre.
Navne på typer kan variere i forskellige programmeringssprog, men der er altid et heltal eller et reelt tal, boolsk værdi, symbol,linje. Der er stadig relikvier og specifikke ideer tilbage: heltal uden fortegn, kode, byte, ord, dobbeltord, streng med fast længde.
Begrebet data i et datasystem har ingen frihed. SQL-sproget - "internation alt" (der er en dialekt for enhver moderne database) - tolererer ikke nogen unøjagtigheder, ikke kun i data, men også i sql-forespørgsler. En fejl i anmodningen er en garanti for fraværet af et resultat. Der er ingen grund til at tale om overtrædelser af beskrivelser overhovedet.
Modellering af informationsprocesser og datarepræsentationer er den eneste sikre måde at opbygge en struktur, der kan udvikle sig og tilpasse sig skiftende forhold.
Dynamics of original
Naturlig information er løbende forandring. At give en formel beskrivelse og koncept af en datamodel inden for et specifikt emneområde betyder at løse tre problemer:
- definer hvilke data der er her;
- formalisere forholdet mellem dem;
- beskriv processer til ændring af data og relationer.
Et eksempel på et datasæt af en simpel algoritme i JavaScript - en reduceret kopi af modellen af selv det mest solide databasestyringssystem.
Det er bare, at i det andet tilfælde ser eksperter og specialister, når de designer datastrukturer, tabeller og relationer, norm alt ikke (det er virkelig svært at dække en stor mængde naturlig information) essensen af ting, og der opnås et besværligt, uudviklet sæt af dynger af data, mens kildeinformation i emneområdet cirkulerer frit og nemt.
Statiskmuligt
Det er almindelig JavaScript-praksis at inkludere kode knyttet til en side og funktioner, der er tildelt begivenheder på sidetags. Uanset hvad, definerer sidetags de data, som en given webressource accepterer, ændrer eller opretter.
Hvis du koncentrerer din handlerkode meget omhyggeligt om elementhændelser og ikke på sidekoden som helhed, er dette den bedste vej ud. Ideelt set, når koden ikke introducerer nye data eller ikke fikser de tilgængelige data, men fokuserer på præcis, hvad den har på et bestemt tidspunkt.
Faktisk, hvis du definerer begrebet "data" som en minim alt statisk beskrivelse af kildeinformationen og følger den, betyder det, at du har en chance for succes.
Med hensyn til databaser er tingene meget mere komplicerede. Enhver JavaScript-kode "forsyner" siden med funktionalitet. Enhver database er en samling af tabeller, relationer mellem dem, lagrede procedurer, forespørgsler og funktionalitet tilgængelig udefra.
Statisk er besværet med enhver algoritme. Det moderne databegreb er statisk: et tal, en streng, et tegn og så videre. Når du behandler eller skriver til en databasetabel, forløber alt problemfrit. Men hvornår får originalen en anden dimension eller betydning? Mulighed 1: skift skiltet, men forbindelser og anmodninger kan falde ind med det samme.
Statik og objekter
Definition af begrebet "data" som et objekt ændrer situationen dramatisk. Objektet har sin egen struktur. Her kan du bruge enhver beskrivelse af alle variabler. Rolle vil ikke spille. Et objekt har metoder, hvorigennem data er tilgængelige. Siden altingbruges inden for programmering, det vil sige tre grundlæggende metoder: læse, skrive, ændre. Du kan tilføje flere for at sammenligne, søge, klone osv.
Fagområdet pålægger hver data en række egenskaber. Dermed viser det sig, at begrebet data omdannes til en slags beskrivelse, der kan ændres dynamisk. Statisk inde i et objekt giver dynamik uden for det.
Når du ændrer kombinationen af statiske deskriptorer inde i et objekt, behøver du ikke bekymre dig om dynamikken i dets relationer med andre objekter.
Programmering og præsentation af data
Hvad er data? Den offentlige bevidsthed er allerede vant til informationsteknologi, arbejder i skyerne og har containere i virtuelle rum. Nu er ikke kun professionelle programmører og brugere, men også almindelige mennesker kompetente i spørgsmål om information og brugen heraf.
Men hvad er programmering? Den dag i dag giver den offentlige mening følgende definition til dette begreb og dets begreber:
- Information og data er de grundlæggende begreber, der bruges i datalogi.
- Data er en bestemt måde modtaget og registreret observationer i forhold til den omgivende virkelighed.
- De er enkle og komplekse (strukturer), primære og sekundære.
- En database er en samling af uafhængige materialer præsenteret på en systematisk måde, så de kan findes, ændres og bruges.
Hvor objektivt er dette? Autoritative forfatteredet tror jeg. Reel praksis har en tendens til at sikre, at hvert fagområde bestemmer dets korrekte datasystem og giver alle muligheder for at opbygge en god dynamisk model.
Det er ikke ualmindeligt, at en kunde (forbruger) påtvinger en programmør (databasedesigner) sin egen mening om, hvordan og hvad man skal gøre. Fra et programmeringssynspunkt kan ethvert ønske hos kunden opfyldes med den største præcision.
Har brug for Oracle for at løse problemet med budgettering for vedligeholdelse af landdistrikternes vandforsyning (bygning 21 i landsbyen) - godt. MySQL er nødvendig for at organisere et sporingssystem for postforsendelser til alle postkontorer i Rusland - alt vil også fungere.
Du kan altid komponere enhver algoritme og give adgang til enhver repræsentation af information inden for definitionen af databegrebet, som er etableret af udvikleren af databasestyringssystemet eller programmeringssproget. Spørgsmålet er anderledes: hvordan gør man det med minimale omkostninger i maksimal dynamik?
Databaser, eksempler
En simpel base skabes uden en model. De grundlæggende begreber for data og kommunikation er små, funktionaliteten er meget enkel. For en videregående uddannelsesinstitution har du for eksempel brug for:
- tabel over lærere;
- gruppetabel (nøgle og gruppenummer);
- generel tabel over elever (gruppenøgler bruges).
Dekanen vil gerne vide lærernes fremskridt. Lærertabellen har felter:
- efternavn;
- navn;
- patronymic;
- overvåget gruppenummer.
Elevtabellen har felter:
- efternavn;
- navn;
- patronymic;
- fødselsdato;
- GPA (for alle fag);
- gruppenummer.
Der kan være mindst to muligheder for stikprøver: ved at bruge navnet på læreren kan du gå til gruppenummeret og se alle eleverne og deres gennemsnitlige score, eller ved at bruge lærerens efternavn og den sidste elevens navn, du kan se den gennemsnitlige score for den sidste.
Selv i en så simpel version er der garanteret problemer, og noget skal ændres. Situation: læreren blev syg, endnu en måned erstatter ham, hvilket betyder, at han overvåger to grupper. Der er kun ét felt under ét gruppenummer i lærertabellen.
For at løse problemet skal du tilføje et dubletfelt. Og hvis to bliver syge, så tilføj tre felter. Så bordet over lærere begynder at vokse fra bunden.
Der er en anden mulighed: Erstat det numeriske felt i gruppetasten med et symbolsk. Derefter, hver gang du vælger, bliver du nødt til at konvertere strengen til en sekvens af nøgler, og en sql-forespørgsel bliver til flere.
Et mere lovende eksempel er ikke at lave tabeller, men at lave objekter. Så er læreren et objekt, og han kan have flere superviserede grupper. Men det er altid én genstand. Lærerobjektet har en unik nøgle, men kan have flere overvågede grupper. Gruppen har også en unik nøgle. En studerende også.
Alle tre stillinger er ikke kun tilgængelige inden for opgaven, men kan videreudvikles.
Objektorienterede baser
Ledere inden for informationsbranchentilbyde klassiske relationsdatabaser. De er testet af livet, de virker, de er sikre, pålidelige, og i tilfælde af problemer giver de dig mulighed for at gendanne information.
Objektorienterede databaser (OODB) begyndte at blive udviklet i midten af 1980'erne og er ifølge autoritative forfattere lovende den dag i dag. Men indtil videre, bortset fra grundlæggende teorier og konceptuelle bestemmelser, er der ingen OODB, der har opnået samme vurdering og distribution som MySQL, MS SQL Server eller Oracle i alle dens forskellige inkarnationer.
Men hvad nu hvis definitionen, begrebet data, typer, attributter, klasser, hierarkier foreslås af en udvikler, hvis vurdering er utilstrækkelig til at skabe et fællesskab af programmører, der bekender sig til mentaliteten i denne OODB? Vi bliver nødt til at stole på vores egen styrke.
Mere end tredive varianter af OODB er blevet oprettet i Linux-miljøet. Men hvor er garantien for, at den oprettede database ikke kræver mere funktionalitet? Windows-miljøet giver ikke mange garantier på dette område.
Objektorienteret løsning
Der er dog en løsning. Ved at bruge MySQL som eksempel kan du vise, hvordan standardrelationstabeller bliver til en objektorienteret model af det problem, der bliver løst.
Der er ingen database her, men der er et miljø til at danne dit eget system af objekter. Kraften i MySQL bruges kun som relationel hukommelse til tabeller fra inforækker. Brugslogikken bestemmes af udvikleren selv. Især er der en is_cache-tabel. Den har altflere grundlæggende felter:
- ejerkode;
- session_code;
- h_code;
- a_surprise;
- a_contents.
Resten af felterne har servicefunktioner. Denne tabel står ved input af enhver anmodning og registrerer dens ankomst. Hvad databasemodellen vil finde ud af, bestemmes af dens udvikler. Hvad der passer i indholdsfeltet (a_contents) bestemmes af objekterne i modellen, der er oprettet af udvikleren.
Der er fire ting i denne idé: hit, hitsession, hithistorikkode og specifikt indhold. Hvad er et opkald, hvilket system af objekter der skal bygges - bestemmes af udvikleren. Hvad der menes med en session (arbejdsproces), bestemmes af udvikleren. Historiekoden er muligheden for at rulle tilbage på anmodninger.
Tabellerne her har intet at gøre med emneområdet. Der er en opkaldscontroller (is_cache), der er logning (is_customs), der er en opkaldshistorik (is_histories). De resterende tabeller bestemmes af den opgave, der bliver løst.
Faktisk foreslår denne løsning at oprette din egen OODB baseret på den indbyggede domænedatabasemodel og problemet, der bliver løst. Der er et kæmpe plus her - dette er dit eget koncept for data, din egen model for deres præsentation og forholdet mellem dem. Der er et fundament her - en stor relationel database. Der vil ikke være nogen problemer med at lede efter noget og misforstå noget.
Model: objektsystem + DBMS
Det er næsten umuligt at ændre noget i informationsteknologien. Den egentlige informationsrevolution er stadig langt væk. faglig bevidsthedsoftwareudviklere kommer ikke til at ændre de klassiske traditioner. Men der er stadig en vej ud af situationen.
Ved at bruge pålidelige moderne databasestyringssystemer som grundlag for at skabe et miljø for eksistensen af din egen model, kan du opnå mærkbar succes.
Under alle omstændigheder bliver du nødt til at bygge en visning eller en datamodel for at løse opgaven, men du skal gøre det korrekt: lad det være et system af objekter, og et godt DBMS være dets miljø.
