Տվյալների բազայի ձեւավորման մեջ տարածված սխալներ

Անկախ նրանից, թե դուք աշխատում եք տվյալների բազայի հետ, որը հարյուրավոր ձայնագրություններ կամ միլիոնավոր գրառումներ ունի, միշտ էլ կարեւոր է տվյալների բազայի դիզայնը: Ոչ միայն այն կդարձնի տեղեկատվությունը շատ ավելի հեշտ գտնելու, այն էլ պարզեցնելու է ապագայում տվյալների շտեմարանի ընդլայնումը: Ցավոք, հեշտ է ընկնել մի քանի թակարդներ, որոնք ապագայում կարող են դժվարություններ առաջացնել:

Կան բազում գրքեր, որոնք գրված են տվյալների բազայի կարգավորմամբ, բայց եթե դուք պարզապես խուսափում եք այդ ընդհանուր սխալներից, ապա դուք ճիշտ ուղու վրա կկարողանաք լավ տվյալների բազայի դիզայն:

Տվյալների շտեմարանի սխալը # 1. Աղյուսակներում կրկնվող դաշտերը

Լավ բազայի դիզայնի հիմնական կանոնն այն է, որ կրկնվող տվյալները ճանաչեն եւ կրկնվող սյունակները դրեն իրենց սեղանի վրա: Աղյուսակում կրկնվող դաշտերը սովորական են այն մարդկանց համար, ովքեր եկել են աղյուսակների աշխարհից, սակայն աղյուսակները հակված են դիզայնի միջոցով, իսկ տվյալների բազաները պետք է լինեն հարաբերական: Այն նման է 2D- ից մինչեւ 3D:

Բարեբախտաբար, կրկնվող ոլորտները սովորաբար հեշտ են տեղում: Պարզապես նայեք այս սեղանին.

Պատվիրիրդ Ապրանք 1 Ապրանք 2 Product3
1 Teddy արջուկներ Ժելե լոբի
2 Ժելե լոբի

Ինչ է տեղի ունենում, երբ պատվերը պարունակում է չորս ապրանք: Մենք պետք է ավելացնեինք եւս մեկ դաշտ դաշտի սեղանին `աջակցելու ավելի քան երեք արտադրանք: Եվ եթե մենք կառուցել ենք հաճախորդի դիմում սեղանի շուրջ, մեզ օգնելու համար մուտքագրելու տվյալները, մենք կարող ենք այն փոփոխել նոր արտադրանքի դաշտում: Եվ ինչպես ենք մենք կարգադրում բոլոր պատվիրանները Jellybeans հետ: Մենք ստիպված կլինենք հարցնել յուրաքանչյուր ապրանքի դաշտը սեղանի մեջ սղության հետ SQL հայտարարությամբ, որը կարող է նման լինել. SELECT * FROM PRODUCTS WHERE Product1 = 'Ժելե լոբի' OR PRODUCT2 = 'Ժելե լոբի' OR PRODUCT3 = 'Ժելե լոբի':

Միակ սեղան ունենալու փոխարեն, որը բաղկացած է բոլոր տեղեկությունները միասին, մենք պետք է ունենանք երեք աղյուսակներ, որոնցից յուրաքանչյուրն ունի հստակ տեղեկատվություն: Այս օրինակում մենք կցանկանայինք պատվիրել սեղան `պատվիրվածի մասին տեղեկություններով, արտադրանքի սեղան` մեր բոլոր ապրանքների եւ ProductOrders պլանշետով, որոնք արտադրանքին պատվիրել են:

Պատվիրիրդ CustomerID- ը Պատվերի ամսաթիվը Ընդամենը
1 7 1/24/17 19.99
2 9 1/25/17 24.99
ProductID- ը Ապրանք Count
1 Teddy արջուկներ 1
2 Ժելե լոբի 100
ProductOrderID- ը ProductID- ը Պատվիրիրդ
101 1 1
102 2 1

Ուշադրություն դարձրեք, թե ինչպես յուրաքանչյուր սեղան ունի իր յուրահատուկ ID դաշտ: Սա առաջնային բանալին է: Մենք սեղաններ ենք կապում `օգտագործելով առաջնային բանալին` որպես այլ աղյուսակի արտաքին բանալի: Կարդացեք հիմնական բանալիների եւ արտաքին բանալիների մասին:

Տվյալների շտեմարանի սխալը # 2. Աղյուսակի ներդիր աղյուսակում

Սա եւս մեկ ընդհանուր սխալ է, բայց դա միշտ չէ, որ նույնքան կրկնվող դաշտեր է առանձնանում: Տվյալների բազան նախագծելիս ցանկանում եք համոզվել, որ սեղանի բոլոր տվյալները վերաբերում են ինքնին: Դա նման է երեխայի խաղին, թե ինչն է տարբերվում: Եթե ​​ունեք բանան, ելակ, դեղձ եւ հեռուստատեսություն, հեռուստացույցը, հավանաբար, ուրիշ տեղ է:

Նույն շարքերում, եթե դուք ունեք վաճառքի մարդկանց սեղան, ապա այդ աղյուսակում առկա բոլոր տեղեկությունները պետք է համապատասխանեն տվյալ վաճառքի անձնին: Ցանկացած լրացուցիչ տեղեկատվություն, որը վաճառքի տվյալ անձի համար յուրահատուկ չէ, կարող է այլ տեղ լինել ձեր տվյալների բազայում:

SalesID Առաջին Վերջինը Հասցե Հեռախոսահամար Գրասենյակ Գրասենյակային թիվ
1 Սամ Էլիոտ 118 Main St, Austin, TX (215) 555-5858 Austin Downtown- ն (212) 421-2412
2 Ալիս Սմիթը 504 2nd Street, Նյու Յորք, NY (211) 122-1821 Նյու Յորք (Արեւելյան) (211) 855-4541
3 Ջո Ծխական 428 Aker St, Austin, TX (215) 545-5545 Austin Downtown- ն (212) 421-2412

Թեեւ այս սեղանը կարող է նման լինել այն ամենին, ինչ վերաբերում է առանձին վաճառողին, այն իրականում ունի սեղանի մեջ ներկված սեղան: Ուշադրություն դարձրեք, թե ինչպես Office եւ OfficeNumber- ը կրկնում են «Austin Downtown» - ի հետ: Ինչ անել, եթե գրասենյակի հեռախոսահամարը փոխվի: Դուք պետք է թարմացնեք մի ամբողջ տվյալների հավաքածու մեկ փոփոխվող տեղեկատվության փոխանակման համար, ինչը երբեք լավ բան չէ: Այս դաշտերը պետք է տեղափոխվեն իրենց սեղանին:

SalesID Առաջին Վերջինը Հասցե Հեռախոսահամար Office ID- ն
1 Սամ Էլիոտ 118 Main St, Austin, TX (215) 555-5858 1
2 Ալիս Սմիթը 504 2nd Street, Նյու Յորք, NY (211) 122-1821 2
3 Ջո Ծխական 428 Aker St, Austin, TX (215) 545-5545 1
Office ID- ն Գրասենյակ Գրասենյակային թիվ
1 Austin Downtown- ն (212) 421-2412
2 Նյու Յորք (Արեւելյան) (211) 855-4541

Այս դիզայնի շնորհիվ Ձեզ հնարավորություն է ընձեռում ավելացնել նաեւ լրացուցիչ տեղեկություններ Office- ի աղյուսակում, առանց վաճառքի անձի սեղանի խառնաշփոթի մղձավանջ ստեղծելու: Պատկերացրեք, թե որքան աշխատանք կլիներ պարզապես հետեւել փողոցի հասցեին, քաղաքին, պետությանը եւ փոստային կոդերին, եթե այդ բոլոր տեղեկությունները վաճառքի անձի սեղանին էին:

Տվյալների շտեմարանի սխալը # 3: Մեկ կամ երկու դաշտում տեղեկատվության ներդիր

Գրասենյակային տեղեկատվության ներդիրը վաճառող անձի սեղանին միակ խնդիրն էր այդ տվյալների բազայի հետ: Հասցե դաշտը պարունակում էր երեք տեղեկություն `փողոցային հասցեն, քաղաքը եւ պետությունը: Տվյալների բազայում յուրաքանչյուր դաշտը պետք է պարունակի միայն մեկ տեղեկատվության պարունակություն: Երբ դուք ունեք մի շարք տեղեկատվության մի դաշտում, այն կարող է դառնալ ավելի դժվար է հարցնել տվյալների բազայի տեղեկատվության համար:

Օրինակ, եթե մենք ուզում էինք հարցումներ անցկացնել Օսթինցի վաճառքի բոլոր մարդկանց համար: Պետք է փնտրել հասցեի դաշտում, որը ոչ միայն անարդյունավետ է, այլեւ կարող է վատ տեղեկատվություն վերադարձնել: Ի վերջո, ինչ է տեղի ունենում, եթե ինչ-որ մեկը ապրում է Օստին փողոցում, Պորտլենդում, Օրեգոն:

Ահա թե ինչ է սեղանը նման:

SalesID Առաջին Վերջինը Հասցե 1 Հասցե 2 Քաղաքը Պետություն Zip Հեռ
1 Սամ Էլիոտ 118 Գլխավոր Սբ Օստին TX- ն 78720 2155555858
2 Ալիս Սմիթը 504 2-րդ փող Նյու Յորք NY 10022 2111221821
3 Ջո Ծխական 428 Աքերի Սբ Դեպի 304 Օստին TX- ն 78716 2155455545

Այստեղ կան մի քանի բան: Նախ, «Address1» եւ «Address2» կարծես ընկնում են կրկնվող դաշտերի սխալի ներքո:

Այնուամենայնիվ, այս դեպքում նրանք առնչվում են առանձին մասերի տվյալների հետ, որոնք ուղղակիորեն վերաբերում են վաճառողին, այլ ոչ թե կրկնվող տվյալների խումբը, որը պետք է գնա իր սեփական աղյուսակում:

Բացի այդ, որպես բոնուսային սխալ, խուսափելու համար, նկատեք, թե ինչպես է հեռախոսահամարի ձեւաչափը հանվել սեղանից: Դուք պետք է խուսափեք դաշտերի ձեւաչափը պահելու հնարավորության դեպքում: Հեռախոսահամարների դեպքում կան բազմաթիվ ուղիներ, որոնք մարդիկ գրում են հեռախոսահամար `215-555-5858 կամ (215) 555-5858: Սա վաճառողներին փնտրում է հեռախոսահամարով կամ նույն տարածքային կոդով վաճառողներին փնտրելու համար ավելի դժվար է:

Տվյալների շտեմարանի սխալը # 4. Չօգտագործել ճշգրիտ առաջնային բանալի

Շատ դեպքերում դուք կցանկանայիք օգտագործել ձեր հիմնական բանալին ինքնաբերաբար ավելացնող համարը կամ որոշ այլ գեներացված համար կամ ալֆա-թվային: Դուք պետք է խուսափեք առանցքային բանալին օգտագործելու որեւէ իրական տեղեկատվություն, նույնիսկ այն դեպքում, երբ այն հնչում է որպես լավ նույնացուցիչ:

Օրինակ, մենք ունենք յուրաքանչյուր սեփական անհատական ​​սոցիալական ապահովության համար, այնպես որ աշխատակիցների տվյալների բազայի համար օգտագործելով սոցիալական ապահովության համարը կարող է լավ գաղափարի նման լինել: Սակայն, հազվադեպ, հնարավոր է նույնիսկ սոցիալական ապահովության համարը փոխվի, եւ մենք երբեք չենք ուզում փոխել մեր առաջնային բանալին:

Եվ դա այն խնդիրն է, որն օգտագործվում է փաստացի տեղեկատվությունը որպես առանցքային արժեք: Այն կարող է փոխվել:

Տվյալների շտեմարանի սխալը # 5. Օգտագործելով անունով կոնվենցիա

Սա կարող է չհամընկնել մի մեծ գործարքի, երբ առաջին անգամ սկսում ես նախագծել ձեր տվյալների բազան, բայց երբ դուք ստանում եք տվյալների բազայի դեմ հարցումների գրելու կետ, տեղեկություն ստանալու համար, անունով համապարփակ պայմանագիր կնքեք, երբ դուք անգիրի դաշտի անունները:

Պարզապես պատկերացրեք, թե որքան ավելի դժվար է այդ գործընթացը, եթե անունները պահվեն որպես Անուն, LastName մեկ սեղանի վրա եւ առաջին_նան, last_name այլ աղյուսակում:

Երկու ամենահեղինակավոր անվանափոխման կոնվենցիաները կապիտալիզացվում են դաշտում յուրաքանչյուր բառի առաջին տառը կամ ընդգծում են բառեր, օգտագործելով ներքեւում: Կարող եք նաեւ տեսնել, որ որոշ ծրագրավորողներ կապիտալիզացնեն յուրաքանչյուր բառի առաջին տառը, բացառությամբ առաջին բառի `առաջինը, անունը, վերջինը:

Դուք նաեւ ցանկանում եք որոշել եզակի սեղանների կամ բազմակի աղյուսակների անունների օգտագործման մասին: Արդյոք դա պատվերի սեղան է կամ Պատվերների սեղան: Հաճախորդների սեղան կամ հաճախորդների սեղան: Կրկին, դուք չեք ուզում խառնել պատվերի սեղանի եւ Հաճախորդների աղյուսակի հետ:

Ընտրած անվանացուցակը ոչ այնքան կարեւոր է, որքան ընտրական կոնվենցիայի իրական ընտրության եւ կախվածության գործընթացը:

Տվյալների շտեմարանի սխալը # 6. Անհամապատասխան ինդեքսավորում

Ինդեքսավորումն ամենավատ բաներից է, որ ճիշտ է, հատկապես այն նորերի համար, որոնք ունեն տվյալների բազայի դիզայն: Բոլոր առաջնային բանալիները եւ օտարերկրյա ստեղները պետք է ինդեքսավորվեն: Սրանք այնպիսին են, որ միասնական սեղանները միասին, այսինքն `առանց ինդեքսի, դուք կտեսնեք շատ վատ կատարում ձեր տվյալների բազայում:

Բայց շատ հաճախ բացակայում են մյուս ոլորտները: Սրանք են «WHERE» դաշտերը: Եթե ​​հաճախ եք նեղվում ձեր որոնումը `օգտագործելով WHERE կետում դաշտ, ցանկանում եք մտածել այդ դաշտի ինդեքսը դնելու մասին: Այնուամենայնիվ, դուք չեք ցանկանում չափազանց ինդեքսավորել աղյուսակը, ինչը կարող է նաեւ վնաս հասցնել կատարողականությանը:

Ինչպես որոշել: Սա տվյալների բազայի նախագծման արվեստի մի մասն է: Չկա որեւէ ծանր սահմանափակում, թե որքան ցուցանիշներ պետք է դրեք սեղանի վրա: Նախեւառաջ, ցանկանում եք նշել ցանկացած դաշտ, որը հաճախ օգտագործվում է WHERE կետում: Կարդալ ավելին ձեր տվյալների բազայի պատշաճ կերպով կատարելու մասին: