Data er vanligvis assosiert med programmering og presenteres i den moderne informasjonsverden i tre logisk likeverdige versjoner: data beskrevet og brukt i et program på et programmeringsspråk; data i databasesystemer; data i distribuerte informasjonssystemer. Moderne programmering har gitt relativ frihet kun til den første varianten av informasjonsformalisering. De to andre alternativene er mer eller mindre pålitelige former for å gi informasjon og forhold mellom komponentene.
Data tidligere og nåtid
Den grunnleggende posisjonen til programmeringsspråk er den nøyaktige beskrivelsen av data og algoritmer. Datamaskiner "presenterer" ingen sjanse for usikkerhet: det er noe som skal handles på, og det er en kommando som utfører den handlingen.
Det moderne konseptet er basert på et mye høyere grunnlag: det er en gitt, og nøyaktig hva det vil være, bestemmes på stedet for dets bruk. I alle fall, på tidspunktet for bruk, blir dataene automatisk kontrollert og konvertert til riktig type. En moderne programmerer er ikke forpliktet til å ta seg av deres foreløpige beskrivelse og overholdelse av typekompatibilitet i algoritmen.
Overgangsprosess:
- fra innskrevne data og dens obligatoriske beskrivelse før bruk;
- til uskrevne data og frihet fra enhver forpliktelse til å beskrive og bruke dem.
Vi kan faktisk gjenkjenne den relative lempelsen av formaliseringskravene - den er kun tilgjengelig i miljøet med moderne programmeringsverktøy. Ved kjøring er typen for hvert datum fast, og kommandosekvensen er veldefinert.
Typer og modellering
Matematikk og fysikk, handel og produksjon, økonomi og andre områder der tall brukes, har alltid operert med data og har ikke lagt vekt på typebegrepet. At tall kan være hele eller brøker spilte ingen rolle.
Hver spesifikk formel eller spesifikk handling kan gi et heltall, uendelig brøk, reelt eller komplekst tall. Til nå er det slike underverker i sinnet som uendelig liten og uendelig stor. Dessuten har disse miraklene til og med egenskaper.
Det er fortsatt ingen frihet i programmering. Alt må være strengt formalisert. Konseptet med data er for det første en type:
- integer;
- boolean;
- char;
- streng og så videre.
Navn på typer kan variere i forskjellige programmeringsspråk, men det er alltid et heltall eller et reelt tall, boolsk verdi, symbol,linje. Det er fortsatt relikvier og spesifikke ideer igjen: usignert heltall, kode, byte, ord, dobbeltord, streng med fast lengde.
Begrepet data i et datasystem har ingen frihet. SQL-språket - "internasjon alt" (det er en dialekt for hver moderne database) - tolererer ingen unøyaktigheter ikke bare i data, men også i sql-spørringer. En feil i forespørselen er en garanti for fravær av et resultat. Det er ikke nødvendig å snakke om brudd på beskrivelser i det hele tatt.
Modellering av informasjonsprosesser og datarepresentasjoner er den eneste sikre måten å bygge en struktur som kan utvikle seg og tilpasse seg endrede forhold.
Dynamics of original
Naturlig informasjon er kontinuerlig endring. Å gi en formell beskrivelse og konsept av en datamodell i et spesifikt fagområde betyr å løse tre problemer:
- definer hvilke data som er her;
- formalisere forholdet mellom dem;
- beskriv prosesser for endring av data og relasjoner.
Et eksempel på et datasett av en enkel algoritme i JavaScript – en redusert kopi av modellen til selv det mest solide databasestyringssystemet.
Det er bare at i det andre tilfellet ser eksperter og spesialister, når de designer datastrukturer, tabeller og relasjoner, vanligvis ikke (det er virkelig vanskelig å dekke en stor mengde naturlig informasjon) essensen av ting, og det oppnås et tungvint, uutviklet sett med hauger med data, mens kildeinformasjonen i fagområdet sirkulerer fritt og enkelt.
Statiskmulig
Det er vanlig JavaScript-praksis å inkludere kode knyttet til en side og funksjoner tilordnet hendelser på sidetagger. Uansett definerer sidetagger dataene som en gitt nettressurs godtar, modifiserer eller oppretter.
Hvis du konsentrerer behandlerkoden veldig nøye om elementhendelser, og ikke på sidekoden som helhet, er dette den beste veien ut. Ideelt sett når koden ikke introduserer nye data eller ikke fikser tilgjengelige data, men fokuserer på nøyaktig hva den har på et bestemt tidspunkt.
Faktisk, hvis du definerer konseptet "data" som en minim alt statisk beskrivelse av kildeinformasjonen og følger den, betyr dette at du har en sjanse til å lykkes.
Når det gjelder databaser, er ting mye mer komplisert. Enhver JavaScript-kode "gir" siden funksjonalitet. Enhver database er en samling av tabeller, relasjoner mellom dem, lagrede prosedyrer, spørringer og funksjonalitet tilgjengelig fra utsiden.
Statisk er problemet med enhver algoritme. Det moderne konseptet med data er statisk: et tall, en streng, et tegn og så videre. Når du behandler eller skriver til en databasetabell, går alt greit. Men når får originalen en annen dimensjon eller mening? Alternativ én: endre skiltet, men tilkoblinger og forespørsler kan falle inn umiddelbart.
Statikk og objekter
Å definere konseptet "data" som et objekt endrer situasjonen dramatisk. Objektet har sin egen struktur. Her kan du bruke hvilken som helst beskrivelse av variabler. Rolle vil ikke spille. Et objekt har metoder som gjør data tilgjengelig. Siden altbrukes innen programmering, det vil si tre grunnleggende metoder: lese, skrive, endre. Du kan legge til flere for å sammenligne, søke, klone osv.
Fagområdet pålegger hver data en rekke egenskaper. Dermed viser det seg at begrepet data transformeres til en slags beskrivelse som kan endres dynamisk. Statisk inne i et objekt gir dynamikk utenfor det.
Hvis du endrer kombinasjonen av statiske deskriptorer inne i et objekt, trenger du ikke å bekymre deg for dynamikken i dets relasjoner med andre objekter.
Programmering og presentasjon av data
Hva er data? Den offentlige bevisstheten er allerede vant til informasjonsteknologi, jobber i skyene og har containere i virtuelle rom. Nå er ikke bare profesjonelle programmerere og brukere, men også vanlige mennesker kompetente når det gjelder informasjon og bruken av den.
Men hva er programmering? Den dag i dag gir opinionen følgende definisjon til dette konseptet og dets konsepter:
- Informasjon og data er de grunnleggende begrepene som brukes i informatikk.
- Data er en bestemt måte mottatte og registrerte observasjoner i forhold til den omgivende virkeligheten.
- De er enkle og komplekse (strukturer), primære og sekundære.
- En database er en samling uavhengige materialer presentert på en systematisk måte slik at de kan finnes, endres og brukes.
Hvor objektivt er dette? Autoritative forfatteretror det. Reell praksis har en tendens til å sikre at hvert fagområde bestemmer sitt korrekte datasystem og gir alle muligheter til å bygge en god dynamisk modell.
Det er ikke uvanlig at en kunde (forbruker) påtvinger en programmerer (databasedesigner) sin egen mening om hvordan og hva de skal gjøre. Fra et programmeringssynspunkt kan ethvert ønske fra kunden oppfylles med den største presisjon.
Trenger Oracle for å løse problemet med budsjettering for vedlikehold av landlig vannforsyning (bygg 21 i landsbyen) - bra. MySQL er nødvendig for å organisere et sporingssystem for postforsendelser for alle postkontorer i Russland – alt vil også fungere.
Du kan alltid komponere hvilken som helst algoritme og gi tilgang til enhver representasjon av informasjon innenfor definisjonen av begrepet data, som er etablert av utvikleren av databasebehandlingssystemet eller programmeringsspråket. Spørsmålet er et annet: hvordan gjøre det med minimale kostnader i maksimal dynamikk?
Databaser, eksempler
En enkel base lages uten modell. De grunnleggende begrepene data og kommunikasjon er små, funksjonaliteten er veldig enkel. For en høyere utdanningsinstitusjon trenger du for eksempel:
- tabell over lærere;
- gruppetabell (nøkkel og gruppenummer);
- generell tabell over elever (gruppenøkler brukes).
Dekanen ønsker å vite fremgangen til lærerne. Lærertabellen har felt:
- etternavn;
- navn;
- patronymic;
- overvåket gruppenummer.
Elevtabellen har felt:
- etternavn;
- navn;
- patronymic;
- fødselsdato;
- GPA (for alle fag);
- gruppenummer.
Det kan være minst to alternativer for prøvetaking: ved å bruke navnet på læreren kan du gå til gruppenummeret og se alle elevene og deres gjennomsnittlige poengsum, eller etter etternavnet til læreren og den siste navnet på eleven, kan du se gjennomsnittlig poengsum for den siste.
Selv i en så enkel versjon er det garantert problemer og noe må endres. Situasjon: læreren ble syk, en annen måned erstatter ham, noe som betyr at han overvåker to grupper. Det er bare ett felt under ett gruppenummer i lærertabellen.
For å løse problemet må du legge til et duplikatfelt. Og hvis to blir syke, så legg til tre felt. Så bordet over lærere begynner å vokse fra bunnen av.
Det er et annet alternativ: erstatt det numeriske feltet til gruppetasten med et symbolsk. Deretter, hver gang du velger, må du konvertere strengen til en sekvens av nøkler, og ett sql-spørring blir til flere.
Et mer lovende eksempel er ikke å lage tabeller, men å lage objekter. Da er læreren et objekt, og han kan ha flere veiledede grupper. Men det er alltid ett objekt. Lærerobjektet har en unik nøkkel, men kan ha flere overvåkede grupper. Gruppen har også en unik nøkkel. En student også.
Alle tre stillingene er ikke bare tilgjengelige innenfor oppgaven, men kan videreutvikles.
Objektorienterte baser
Ledere i informasjonsbransjentilby klassiske relasjonsdatabaser. De er testet av livet, de fungerer, de er trygge, pålitelige, og i tilfelle problemer lar de deg gjenopprette informasjon.
Objektorienterte databaser (OODB) begynte å bli utviklet på midten av 1980-tallet og er ifølge autoritative forfattere lovende den dag i dag. Men så langt, bortsett fra grunnleggende teorier og konseptuelle bestemmelser, er det ingen OODB som har oppnådd samme rangering og distribusjon som MySQL, MS SQL Server eller Oracle i alle dens forskjellige inkarnasjoner.
Men hva om definisjonen, konseptet med data, typer, attributter, klasser, hierarkier er foreslått av en utvikler hvis vurdering ikke er tilstrekkelig til å skape et fellesskap av programmerere som bekjenner mentaliteten til denne OODB? Vi må stole på vår egen styrke.
Mer enn tretti varianter av OODB er laget i Linux-miljøet. Men hvor er garantien for at den opprettede databasen ikke vil kreve mer funksjonalitet? Windows-miljøet gir ikke mange garantier på dette området.
Objektorientert løsning
Det finnes imidlertid en løsning. Ved å bruke MySQL som eksempel kan du vise hvordan standard relasjonstabeller blir til en objektorientert modell av problemet som løses.
Det er ingen database her, men det er et miljø for å lage ditt eget system av objekter. Kraften til MySQL brukes kun som relasjonsminne for tabeller fra inforader. Brukslogikken bestemmes av utvikleren selv. Spesielt er det en is_cache-tabell. Den har altflere grunnleggende felt:
- owner_code;
- session_code;
- h_code;
- a_surprise;
- a_contents.
Resten av feltene har servicefunksjoner. Denne tabellen står ved inngangen til enhver forespørsel og registrerer ankomsten. Hva databasemodellen vil finne ut avgjøres av utvikleren. Hva som får plass i innholdsfeltet (a_contents) bestemmes av objektene til modellen laget av utvikleren.
Det er fire ting i denne ideen: treff, trefføkt, treffhistorikkkode og spesifikt innhold. Hva er en samtale, hvilket system av objekter som skal bygges - bestemmes av utvikleren. Hva som menes med en økt (arbeidsprosess) bestemmes av utvikleren. Historiekoden er muligheten til å rulle tilbake på forespørsler.
Tabellene her har ingenting med fagområdet å gjøre. Det er en samtalekontroller (is_cache), det er logging (is_customs), det er en samtalehistorikk (is_histories). De resterende tabellene bestemmes av oppgaven som løses.
Faktisk foreslår denne løsningen å lage din egen OODB basert på den bygde domenedatabasemodellen og problemet som blir løst. Det er et stort pluss her - dette er ditt eget konsept for data, din egen modell av presentasjonen deres og forholdet mellom dem. Det er et fundament her - en flott relasjonsdatabase. Det vil ikke være noen problemer med å lete etter noe og misforstå noe.
Modell: objektsystem + DBMS
Det er nesten umulig å endre noe innen informasjonsteknologi. Den virkelige informasjonsrevolusjonen er fortsatt langt unna. faglig bevissthetprogramvareutviklere kommer ikke til å endre de klassiske tradisjonene. Men det er fortsatt en vei ut av situasjonen.
Ved å bruke pålitelige moderne databasestyringssystemer som grunnlag for å skape et miljø for eksistensen av din egen modell, kan du oppnå merkbar suksess.
I alle fall må du bygge en visning eller en datamodell for å løse oppgaven, men du må gjøre det riktig: la det være et system av objekter, og et godt DBMS være dets miljø.
