Føler du dig overvældet over den tid, det vil tage dig at lære at blive databasedesigner? Læs om de væsentlige færdigheder og talenter, du har brug for - det er ikke så forfærdeligt!
Når du går ned ad gangene i supermarkedet, med indkøbskurv i den ene hånd og indkøbsliste i den anden, hvad tænker du så? Hvis du er ligesom mig, forestiller du dig, hvordan du kan forbedre organiseringen af hylderne, så dine ugentlige indkøb er mindre tidskrævende. Eller måske føler du det samme ønske om at organisere og strukturere information, når en ven viser dig deres store samling af magasiner. Eller måske slår det, når du administrerer dine afspilningslister, så de passer bedre til dine præferencer. Hvis du går gennem livet og tænker på, hvordan du repræsenterer virkeligheden i form af entiteter, attributter og relationer, så er dit kald at være databasemodeller.
Måske er du ikke helt så ekstrem, men du er stadig tiltrukket af ideen om at forfølge databasedesign som en karriere. Uanset hvad, bliver du nødt til at mestre et par nye færdigheder. Nogle af dem er rent tekniske; du kan lære disse færdigheder ved at studere eller læse og uddybe dem gennem erhvervserfaring. Andre færdigheder involverer ikke-teknisk viden, som du kan lære gennem kurser, blogartikler eller ved at observere andre.
Her er en oversigt over den væsentlige viden og færdigheder, som enhver databasedesigner skal have.
Hårde færdigheder databasedesignere har brug for
Hårde færdigheder er dem, der erhverves gennem studier og finpudset gennem praksis. Hvis du med konkrete beviser kan demonstrere, at du har mestret en hård færdighed, betyder det, at du er i stand til at udføre enhver opgave, der involverer det.
Med hensyn til databaseviden omfatter hårde færdigheder det grundlæggende i databaseteori og de forskellige teknikker, der bruges til at anvende teoretiske begreber til at løse konkrete problemer. Lad os se på hver af de hårde færdigheder, som databasedesignere har brug for.
Databaseteori
Databaseteori er fuld af abstrakte begreber, som kan være svære at forstå, hvis de ikke er forbundet med virkelige fakta. Den relationelle model, domæner, attributter, relationer og relationer, primære og fremmede nøgler, entitetsintegritet, referentiel integritet og domænebegrænsninger er blot nogle få eksempler. Hvis du tilføjer endnu mere komplekse emner (såsom relationel algebra eller relationel calculus), kan du undre dig over, om det ikke ville være bedre at vælge en karriere, der beskæftiger sig med konkrete ting som havearbejde eller gourmetmadlavning.
Gå ikke i panik. Grundig kendskab til databaseteori er vigtig, hvis du planlægger at undervise i collegeklasser eller opfinde en ny måde at organisere information på. Men for at designe databaser behøver du kun at mestre de teoribegreber, der gælder for løsning af virkelige problemer. Den vigtigste – databasedesignets ABC – er den relationelle model.
Den relationelle model
Universitetsprofessorer vil fortælle dig, at den relationelle model er en dataorganiseringsmekanisme baseret på mængdeteori og prædikatlogik. Men det vil ikke gavne dig meget i dit daglige arbejde som databasemodeller. I praksis skal du vide, at relationsmodellen er en intuitiv og ligetil måde at organisere data på i form af tabeller – kaldet relationer – som er sammensat af rækker (som også kaldes tupler). Hver tabel (eller relation) er defineret af dens attributter (eller kolonner).
Grundlæggende begreber i relationsmodellen.
Alle relationer skal have en eller flere udestående attributter, der repræsenterer en unik identifikator for hver tupel. I databaseslang er det nøglen til bordet. Ikke-nøgleattributter er nøgleafhængige i den forstand, at hver nøgleværdi bestemmer en enkelt mulig værdi for hver attribut.
Forestil dig en tabel med køretøjsoplysninger, hvor nøglen er nummerpladen. Nummerpladen bestemmer attributterne for hvert køretøj (såsom producent, model, ejer osv.), da reglerne for domænet forhindrer to forskellige køretøjer, der deler den samme nummerplade.
Relationelle databaser
Relationelle databasestyringssystemer (RDBMS'er) implementerer relationsmodellen under respekt for dens principper. De tilbyder måder at hente information gennem forespørgsler og opdatere information gennem transaktioner. For at oplysningerne i en relationsdatabase skal afspejle virkelige fakta og situationer, kan du definere betingelser eller begrænsninger, der er specifikke for det domæne, som databasen gælder for. For eksempel, i en tabel, der gemmer oplysninger om skoleelever, kan der indføres en begrænsning, så fødselsdatoerne ikke tillader fremtidige datoer eller datoer, der ligger for langt tilbage i fortiden.
Organiseringen af tabeller i en database omtales almindeligvis som databaseskemaet. Ud over tabeller detaljerer skemaet begrænsninger, der involverer par af tabeller kaldet relationer. En relation forbinder to tabeller ved at pålægge den begrænsning, at værdierne i feltet i en af tabellerne svarer til værdier i den primære nøgle i den anden tabel.
Databaseskemaer er normalt repræsenteret af entity-relationship diagram (ERD), et almindeligt værktøj for enhver databasedesigner.
En ERD, der repræsenterer en kundedatamodel.
Anomalier og normalisering
Alle de begreber, vi har diskuteret indtil videre, er ret klare, ikke? Nu kan vi tale om de anomalier, der opstår i databaser på grund af mangelfuldt eller utilstrækkeligt design (dvs. databasen afspejler ikke tilstrækkeligt den virkelighed, den forsøger at repræsentere).
Anomalier opstår, når en indsættelses-, opdaterings- eller sletningshandling genererer uoverensstemmelser i dataene. Antag for eksempel, at du har en tabel til at gemme salgsdata. For hvert salg (dvs. i hver post i tabellen) registreres kundernes navn og adresse. Anomalien er som følger:
- Hvis kundens adresse er ændret i et af udsalgene, og
- Samme kunde har andre salg,
- De øvrige salg vil have en forældet adresse.
For at undgå uregelmæssigheder kan du anvende en designteknik kaldet databasenormalisering. Dette involverer nedbrydning af tabeller og kolonner (dvs. opdeling af dem i mindre dele) for at undgå designfejl som:
- Kolonner, der indeholder mere end én information (f.eks. en vares id-nummer samt dens navn).
- Gemmer de samme oplysninger mere end én gang i den samme tabel.
- Felter, der afhænger af andre ikke-nøglefelter.
Ikke-normaliseret tabel (venstre) versus normaliseret skema (højre).
Datavarehuse og denormalisering
Nogle databaser bruges til at forespørge store mængder information i stedet for online transaktionsbehandling (OLTP). Disse databaser kaldes datavarehuse.
Oplysningerne i et datavarehus kommer ikke fra brugergrænseflader (fx indtastet direkte fra et e-handelsbestillingssystem). Det kommer fra batch-processer, der indsamler information fra forskellige kilder, behandler det, renser det og gemmer det i tabeller. Af denne grund kan vi antage, at datavarehuse ikke er udsat for de samme anomalier som konventionelle databaser.
På grund af det behøver datavarehuse ikke at opretholde de samme normaliseringsbetingelser som en OLTP-database. På den anden side er det vigtigere at optimere forespørgselseffektiviteten i datavarehuse. Det er derfor, denormalisering anvendes i et datavarehus; denne teknik bruger en vis mængde redundans til at forenkle forespørgsler og undgå at rode skemaer med et for stort antal tabeller.
Et typisk datavarehus-skema.
Big Data
Ligesom data warehousing refererer konceptet Big Data til depoter, der rummer store mængder data. Der er dog en vigtig forskel mellem de to begreber. Et datavarehus er designet til et specifikt formål og har til formål at generere rapporter, hvis adfærd og format er kendt på forhånd.
Big Data har på den anden side til formål at indsamle store mængder data, der genereres med høj hastighed fra forskellige kilder – f.eks. information fra sociale medier, mikrotransaktioner eller smarte sensorer. Denne enorme mængde information kan bruges til udforskning og analyse eller til træning af maskinlæringsmodeller.
I Big Data-databasedesign prioriteres lagerpladsøkonomi og datapartitionering (blandt andet) for at muliggøre parallelitet og datafangst i realtid. Derudover anvendes ikke-relationelle eller NoSQL-databasesystemer, som tilbyder bedre alternativer til håndtering af ustruktureret information.
Teknologier som NoSQL og selve konceptet Big Data er relativt nyt i forhold til relationelle databaser, som allerede er mere end 40 år gamle. Derfor skal du som databasedesigner være opmærksom på nye udviklinger på området. Husk på, at Big Data også er big business. Mange virksomheder ønsker at tage en førende position inden for det og udvikler nye værktøjer og teknologier til at gøre det.
Databaseadministration
Når først en database er oppe at køre, skal nogen tage sig af dens daglige ledelse. Det betyder at udføre rutineopgaver, så databasen aldrig bliver en flaskehals for de applikationer, der bruger den. Administrationsopgaver omfatter vedligeholdelse af sikkerhedskopier, overvågning af lagerpladsforbrug, registrering af nedbrud mellem processer og reparation af dataproblemer, der forhindrer applikationers normale drift.
Den person, der har databasekompetencerne til at varetage disse opgaver, er databaseadministratoren, eller DBA – når der er en. I meget små organisationer – eller i udviklingsmiljøer, hvor driften af databaserne ikke er kritisk for virksomheden – kan ansvaret for databasevedligeholdelsen påhvile databasemodelleren. Derfor bør du have noget viden, der gør, at du kan tage over fra DBA i visse situationer. Du bør dog under ingen omstændigheder acceptere ansvaret for at administrere en database i et produktionsmiljø, der understøtter forretnings- eller missionskritiske applikationer .
Administrationsopgaver varierer meget afhængigt af databasesystemet og den infrastruktur, det er monteret på. For eksempel er opgaverne med at administrere Microsoft SQL Server-databaser meget forskellige fra dem til at administrere MySQL- eller Oracle-databaser. Og at administrere en server, som du kører lokalt på din notebook, er meget anderledes end at administrere en, der kører i skyen.
Jeg anbefaler ikke at dedikere en masse kræfter til at lære at administrere en bestemt databaseserver, da du vil beskæftige dig med meget forskellige databaser og miljøer gennem din karriere. Det hjælper dig ikke meget at specialisere dig i kun én.
Samtidigheds- og transaktionsstyring
Samtidig adgang til en database kan forårsage problemer i applikationer, når flere brugere forsøger at få adgang til den samme ressource på samme tid. Vi tror måske, at det som designere ikke er vores sag, og at det er DBA's ansvar at håndtere disse problemer. Vi tror måske også, at det er programmørernes skyld i at skabe applikationer, der tillader dem.
Designere kan dog gøre deres del for at minimere potentielle samtidighedsproblemer ved at designe skemaer, der undgår dem.
Mange samtidighedsproblemer opstår, når lange og komplekse transaktioner udføres på en database; mens transaktionen behandles, er de involverede tabeller blokeret for andre processer, der har brug for dem til at læse eller skrive information. For at undgå denne form for problemer er det bedste, du kan gøre, at sikre, at dine designs overholder mindst op til den tredje normale form. Så vil det være programmørens ansvar at gennemtænke transaktionerne korrekt for at undgå dødvande.
Men du kan også bruge strategier, der undgår samtidighed, såsom partitionering af skemaer eller gruppering af tabeller efter den funktion, som hver enkelt opfylder.
Lad os forestille os en database til en e-handelsside. Du kan placere stamdatatabellerne for produkter, lager og priser i ét skema og ordrer og salg i et andet sammen med visninger eller skrivebeskyttede replikaer af tabellerne fra det første skema. Dette hjælper med at undgå fejl ved udførelse af transaktioner, der opdaterer stamdataene.
Databasedesignværktøjer
Hvis du forstår den relationelle model, entitets-relationsdiagrammer og normaliseringsteknikker, kan du designe databaser uden andet værktøj end blyant og papir. Din ydeevne vil dog blive væsentligt forbedret, hvis du bruger et intelligent værktøj, især et, der kan automatisere visse designopgaver som at flytte eller ændre objekter i et diagram, opdage designfejl, generere SQL-scripts til at oprette eller opdatere en database og reverse- konstruktion af et eksisterende databasedesign.
At mestre et specialiseret værktøj såsom Vertabelo-platformen vil give dig mulighed for at arbejde meget hurtigere. Og det vil give dig mulighed for at skille dig ud fra andre designere, der ikke har denne hjælp.
SQL og programmering
Vi vil alle gerne kunne levere et databasedesign, sige stolt "Mit arbejde her er gjort" og tage afsted på en velfortjent ferie. Men normalt sker den ideelle situation aldrig. Når du er færdig med dit design, skal applikationsprogrammørerne bruge det, og de skal have dig til at hjælpe dem.
En måde, du bør fortsætte med at assistere i et udviklingsprojekt, er at skrive visninger, triggere, lagrede procedurer og andre ting i SQL (Structured Query Language) for at løse særlige applikationsbehov. En anden måde er at overvåge de programmeringsopgaver, der udføres med noget, der kaldes Object-Relational Mapping (ORM).
ORM'er er beregnet til at abstrahere dataadgang fra et bestemt RDBMS. Den gode side af dette er, at programmører ikke behøver at bekymre sig om detaljerne i den database, de vil bruge - med andre ord, de behøver ikke at være ligeglade med, om RDBMS er MySQL, Oracle, IBM DB2, MS SQL Server , eller noget andet.
Ulempen ved ORM'er er, at databasedesignobjekterne - tabeller, attributter og relationer - er defineret i koden for et programmeringssprog på højt niveau som Java, Python, R eller C#. Med andre ord, de er der, hvor vi databasedesignere ikke kan se dem.
Løsningen på dette problem ligger i Agile udviklingsmetoder og deres samarbejdsfilosofi. Disse fremmer designere og programmører, der arbejder sammen i løbet af et projekt, så du ønsker at bevare et godt forhold til programmørerne. Du bør være villig til at sidde ved siden af dem, se på programmeringskoden og i fællesskab skrive definitionerne af dataobjekterne.
Soft Skills Database Designere bør have
Ud over den teoretiske og tekniske viden, der er specifik for databasedesign, bør en designer ideelt set have andre færdigheder kendt som 'bløde færdigheder'. Disse færdigheder – som at være en god kommunikator og forstå virksomhedens vision for det endelige produkt – påvirker indirekte dit arbejdes succes. Dem, jeg nævner nedenfor, er blot nogle få eksempler, men der er mange flere bløde færdigheder, som i høj grad værdsættes af potentielle arbejdsgivere.
Forretningsvision
Når du designer en database, repræsenterer du en virksomheds virkelighed i form af indbyrdes relaterede dataobjekter. Vi har set, at designet skal opfylde standardiseringsbetingelser, og at det skal undgå uoverensstemmelser, anomalier og samtidighedsproblemer. Men lige så vigtigt – eller måske mere – er det, at designet er i overensstemmelse med forretningsvisionen om den, der betaler din løn.
Forståelse af forretningsvisionen vil give dig mulighed for bedre at forstå vigtigheden af hvert krav og vejlede dine beslutninger, så dine designs er bedre tilpasset organisationens mål.
Her er et simpelt eksempel på, hvordan forståelsen af forretningsvisionen vil forme dit arbejde. Du tror måske, at brugen af en surrogatnøgle i et bord roder dit design og tilføjer et unødvendigt og irriterende element. Men ved at udelade surrogatnøglen, kan du forsinke forespørgsler på den tabel, fordi en nøgle af INTEGER-typen kunne give overlegen ydeevne. Hvis forretningsvisionen er at levere hurtige forespørgsler, så er surrogatnøglen vejen at gå.
Kommunikationsfærdigheder
Det er ikke nok at lave flotte designs. Du skal også kunne forklare, hvorfor dit design virker. Måden at gøre dette på er at vide, hvordan man præsenterer det, både diskursivt (talt eller skriftligt) og visuelt.
Lav en liste over styrkerne ved dit design, så de skiller sig ud. Tænk over de beslutninger, du har truffet for at oprette det, og skriv årsagerne til disse beslutninger ned. Vær forberedt på at forsvare dine beslutninger og dit design over for dem, der ikke forstår det, eller som ønsker at ændre det, hvilket gør det ufuldkomment eller mangelfuldt.
Men du skal også være villig til at tage imod konstruktiv kritik og overveje synspunkter, der er forskellige fra dine egne. Nogle gange kan en programmør opdage et problem, du ikke så, og give dig gode råd. Afskedig ikke dine kolleger, fordi de tror, de ikke har databasekendskab.
Interpersonelle færdigheder
Jeg har kommenteret ovenfor om fordelene ved at have et godt forhold til programmører. Uanset hvor avanceret du er inden for dit ekspertiseområde, er det vigtigt, at du bevarer en kammeratskabsholdning med alle teammedlemmer, uanset om det er en tester, der har opdaget en defekt, der tvinger dig til at gentænke en del af dit design, eller en projektleder, der har brug for du skal udføre en opgave inden for en bestemt dato. Kort sagt, du skal være en holdspiller . Ingen ønsker at have primadonnaer på deres hold, som føler sig uerstattelige og ønsker at påtvinge deres regler.
Det kan ske, at du ikke er den eneste databasedesigner i et udviklingsteam. Måske skal du lede en undergruppe af dine kollegaer. For at gøre det skal du demonstrere lederevner og fungere som projektleder, der sikrer, at teamet af databasedesignere opfylder sine mål og forbliver motiverede.
Sådan lærer du færdigheder i databasedesign
Du kan tilegne dig de færdigheder, du behøver for at være databasedesigner, fra universitetsgrader, kurser, bøger og specialiserede artikler. Fordelen ved universitetskurser er, at de giver dig al den viden, du har brug for, og understøtter den viden med en anerkendt grad. Ulempen er, at de kræver en stor investering af tid og penge.
Hvis du foretrækker at lære på egen hånd ved at læse bøger og artikler, sparer du tid og penge – men du skal bruge en guide til at lede dig gennem de væsentlige emner og til at vurdere din viden. Og du bliver nødt til at demonstrere din viden på en praktisk måde, da du ikke har en uddannelse til at bakke den op.
Uanset om du lærer ved at tage kurser eller læse, vil den viden kun tjene som et fundament. Du lærer mest ved at skabe modeller, stå over for virkelige problemer og observere dine kollegers og kollegers handlinger.