Datu-basearen diseinuan egindako Ohiko akatsak

Erregistro ehunka edo milioika erregistroak dituen datu base batekin lan egiten ari den ala ez adierazten du, datu-basearen diseinu egokia beti garrantzitsua da. Informazio hori askoz ere errazagoa bihurtuko du, etorkizunean datu-basea handitzea erraztuko du. Zoritxarrez, erraza da etorkizunean zailtasunak sor ditzakeen tranpak gutxitzea.

Datu-base bat normalizatzeko gaiari buruzko idatzizko liburuak daude, baina akats komunak saihesten badituzu, bide-izen egokian datu baseen diseinura iritsiko zara.

Base de datos de error 1: taula bateko eremuak errepikatuz

Oinarrizko oinarrizko arau bat datu baseen diseinurako da datuak errepikatzea eta errepikatzea zutabe horiek beren mahai propioa jartzea. Taulan dauden eremuak errepikatzea ohikoa da kalkulu-orrien munduan etortzen direnentzat, baina kalkulu-orriak diseinuak laua izaten jarraitzen duten bitartean, datu-baseak erlazionalak izan behar lirateke. 2D-tik 3D-ra joaten da.

Zorionez, eremu errepikakorrak normalean erraz gelditzen dira. Begiratu taula honetatik:

Zer gertatzen da ordena batek lau produktu dituela? Taulan beste eremu bat gehitu behar genuke hiru produktu baino gehiago laguntzeko. Eta mahaiaren inguruan bezeroaren eskaera eraiki badugu datuak sartzeko laguntzeko, produktu berriaren eremua aldatu beharko genuke. Eta nola aurkitzen ditugu agindu guztiak Jellybeans-ekin? Galdetu beharko genuke mahai bakoitzean produktuaren eremuan kontsulta daitekeen SQL adierazpenarekin: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' OR Product2 = 'Jelly Beans' OR Product3 = 'Jelly Beans'.

Informazio osoa biltzen duen taula bakar bat izan beharrean, hiru taulan eduki beharko genituzke informazio zehatza. Esate baterako, eskaera-taula bat eskatuko genizuke Ordenaren inguruko informazioarekin, gure produktuen Table produktuak eta Produktu-Ordenagailu tabletarekin lotutako produktuak.

Kontuan izan taula bakoitzak bere ID bakarra duen eremua. Hau da gako nagusia. Taula lotzen dugu lehen mailako gako-balioa erabiliz, atzerriko gako bat beste taula batean. Irakurri lehen mailako gakoei eta atzerriko gakoei buruz.

Base de datos de error # 2: mahai batean mahai bat txertatu

Hau da beste akats komun bat, baina ez da beti nabarmentzen eremu errepikakorrak bezainbeste. Datu-base bat diseinatzean, taula batean datu guztiak bere kabuz erlazionatzen direla ziurtatu nahi duzu. Haurraren jokoa bezalakoa da zer den desberdina. Banana, marrubia, melokotoi bat eta telebista bat badituzu, telebistako telesailak beste nonbait baditu.

Ildo beretik, salmentako pertsonen taula bat baduzu, taula horretako informazio guztia salmentako pertsona horri lotu beharko litzaioke. Salmentako pertsona horientzako bakarra ez den informazio gehigarria zure datu-baseko beste nonbait izan daiteke.

Mahai hau agian banakako saltzaileekin erlazionatuta dagoela dirudi, taulan txertatuta dagoen taulan ere badago. Konturatu nola Office eta OfficeNumber errepikatu "Austin Downtown" rekin. Zer gertatzen da bulego-telefono zenbakia aldatzen bada? Datu multzo berri bat eguneratzeko behar duzu informazio zati bakar bat aldatuz, eta hori ez da inoiz gauza ona. Eremu hauek beren mahaira eraman behar dira.

Diseinu mota honek, gainera, informazio osagarria ematen dio Bulegoko mahaiari, gehiegizko amesgaizto bat sortuz salmentako pertsonan. Imajinatu zenbat lan egiteak kalean, hiri, estatu eta zip kodeen jarraipena egin beharko luke informazio hori guztia salmentako pertsonan!

Sarrera datu-basea # 3: Bi eremu edo eremu bakarrean sartu

Bulegoko informazioa biltze taula pertsonalean sartu ez zen datu-basea duen arazo bakarra. Helbide eremuak hiru informazio-zati ditu: kalea helbidea, hiria eta estatua. Datu-baseko eremu bakoitzak informazio zati bakarra eduki behar du. Informazio gehiago nahi izanez gero, eremu bakarrean informazio zati bat baino gehiago bilakatzen da informazioaren datu-basea kontsultatzeko.

Esate baterako, Austin-eko salmentako pertsona guztiei galdetu nahi badigute? Helbideen eremuan bilatu beharko genuke, ez da eraginkorra soilik, baina informazio txarra itzul daiteke. Azken finean, zer gertatzen da norbait Austin Portlanden, Oregonen bizi balitz?

Hona hemen mahaiaren itxura:

Hemen nabarmentzeko gauza pare bat daude. Lehenik eta behin, "Helbidea1" eta "Helbidea2" errepikakorrak diren eremuen akatsen azpian agertuko lirateke.

Hala ere, kasu honetan salmentako pertsonari zuzenean lotzen zaizkion datu zatiak aipatzen dira, bere taula propioa behar duten datu taldeen errepikapena baino.

Halaber, saihestu beharreko bonusen akats gisa, ohartu nola telefonoaren zenbakia formateatu den taulatik atera da. Balio guztien formatua gordetzeko saihestu behar duzu. Telefono zenbakien kasuan, hainbat modu daude jendeak telefono zenbaki bat idazteko: 215-555-5858 edo (215) 555-5858. Horrela, salmentako pertsona bat telefono zenbakiarekin bilatuko litzateke edo salmentak egiten dituzten pertsonei eremu zaileko eremu bereko bilaketa egitea.

Base de datos de error 4: lehen mailako gako zuzena ez erabiltzea

Kasu gehienetan, automatikoki zenbaki bat edo beste sortutako zenbaki bat edo alfanumerikoa zure lehen mailako tekla erabiltzea nahi duzu. Gako nagusiaren benetako informazioa erabiltzea saihestu beharko zenuke, nahiz eta identifikatzaile ona izan.

Esate baterako, bakoitzak berezko gizarte-segurantzako zenbakia dugu, beraz, langileen datu-basean gizarte-segurantzako zenbakia erabiliz ideia ona dirudi. Baina arraroa den arren, posible da gizarte segurantzako zenbaki bat aldatzea, eta inoiz ez dugu nahi gure gako nagusia aldatzea.

Hori da arazoa, benetako informazioa balio gako gisa erabiliz. Aldatu egin daiteke.

Sarrera datu-basea # 5: Naming hitzarmenik ez erabiltzea

Baliteke hau ez izatea akats handirik gertatu denean zure datu-basea diseinatzen hasi zarenean, baina datak datu-basearen aurkako kontsultak egiteko orduan informazioa berreskuratu ahal izateko, izendako konbentzio bat egiteak eremu-izenak ikasi ahal izango ditu.

Irudikatu zenbat prozesu gehiago izango liratekeen izenak FirstName, LastName, mahai batean eta first_name, last_name, beste taula batean gordetzen ziren.

Bi izendapen ezagunen konbentzioek eremuan hitz bakoitzeko lehenengo hizkia kapitalizatzen dute edo azpimarra erabiliz hitzak bereiztuz. Garatzaile batzuek hitz bakoitzeko lehenengo letra maiuskulak ere ikus ditzakezu, lehenengo hitza izan ezik: firstName, lastName.

Mahai-izen berezi edo mahai-izen ugari erabiliz erabaki dezakezu. Agindu taula bat edo eskaera taula bat? Bezeroen taula edo Bezeroen taula al da? Berriz ere, ez duzu ordenarekin eta Bezeroen mahai batekin itsatsita egon nahi.

Aukeratutako izendatze konbentzioa ez da izendapen konbentzioaren aukeratzerakoan eta itsasteko prozesuan bezain garrantzitsua.

Base de datos de error # 6: indizearen okerra

Indizea eskuinera lortzeko gauza zailenetakoa da, bereziki datu-baseko diseinuan. Lehen mailako gako eta atzerriko gako guztiak indexatu behar dira. Esteka-taulak elkarrekin daude, beraz, indize gabe, zure datu-basearen errendimendu oso txarra ikusiko duzu.

Baina askotan ez dira ohikoak beste arloak. Hauek dira "NON" eremuak. Zure bilaketa estutzeko WHERE klausula batean eremu bat erabiltzen baduzu, eremu horretan indize bat jarri nahi baduzu, pentsatu nahi duzu. Hala ere, ez duzu gehiegi taula indexatu nahi, baina errendimendua ere kaltetu dezake.

Nola erabaki? Datu-basearen diseinuaren artearen zati da. Ez dago mahai gainean jarri behar dituzun indize zenbateko mugak. Batez ere, NON klausula batean maiz erabiltzen den edozein eremu indexatu nahi duzu. Irakurri gehiago zure datu-basea indexatzeko moduari buruz.