Ito ang ikatlong bahagi ng serye, Five Normal Forms. Ang mga pamagat ng unang dalawang bahagi (tutorial) ay First Normal Form, na sinusundan ng Second Normal Form. Sa bahaging ito ng serye, ipinaliwanag ang Third Normal Form.
Ang paliwanag ay sumusunod sa linya ng kuwento: Isang ama ang namatay at nag-iwan ng pera para sa kanyang anak. Nagpasya ang anak na i-invest ang pera sa isang convenience store. Ang convenience store, na kilala rin bilang convenience shop, ay isang maliit na retail na negosyo na tumatanggap ng mga pang-araw-araw na item mula sa mga supplier at nagbebenta ng mga ito sa mga indibidwal na customer sa kapitbahayan.
Sa puntong ito, ang tindahan ay naka-stock na, at ang ilang mga benta ay nagawa na. Ang anak, na siyang may-ari ng negosyo, ay may ilang empleyado, na tinatawag na mga klerk sa tutorial na ito. Ang may-ari at sinumang empleyado ay maaaring tumanggap ng mga supply at gumawa ng mga benta pagkatapos i-record ang mga produkto.
Gayunpaman, bago magsimula ang tindahan, walang alam ang may-ari o ang mga empleyado tungkol sa mga normal na anyo. Kaya, nire-record nila ang lahat bilang mga transaksyon sa isang table at isang exercise book. Wala silang computer.
Ikaw, ang mambabasa, ay nakumpleto ang limang bahagi ng serye ng tutorial na ito; isa ka na ngayong database developer. Ang nagmamay-ari ng convenience shop ay iyong kaibigan. Bumisita ka sa tindahan dalawang araw na ang nakalipas at sinanay ang may-ari at ang mga klerk sa paggawa ng mesa sa una nitong normal na anyo. Bumisita ka rin sa shop kahapon at sinanay sila kung paano gumawa ng table sa pangalawang normal na anyo mula sa unang normal na anyo.
Ngayon, kararating mo lang sa shop para sa isang pagbisita upang sanayin sila kung paano gumawa ng talahanayan sa ikatlong normal na anyo mula sa pangalawang normal na anyo. Ang lahat ng mga talahanayan na mayroon sila sa kasalukuyan ay nasa pangalawang normal na anyo. Ang mga talahanayan (ayon sa pangalan at mga heading ng column) ay:
Mga Produkto(productID, categoryID, produkto)
Mga Kategorya(categoryID, kategorya)
Mga benta(saleID, customer, empleyado, petsa)
Mga Detalye ng Pagbebenta(saleID, productID, numberSold, sellingPrice)
Mga order(orderID, supplier, empleyado, petsa)
Mga Detalye ng Order(orderID, productID, numeroBinili, costPrice)
Ang mga single o composite key ay may salungguhit.
Matapos ibuod kung ano ang itinuro sa nakaraang dalawang araw at bago mo magawa ang anumang bagay, itatanong ng may-ari:
“Paano ang mga numero ng telepono, address, atbp., para sa mga customer at empleyado?
Paano naman ang dami ng stock, antas ng muling pagkakaayos, atbp., para sa mga produkto?
Kailangan ba nila ng sarili nilang hiwalay na mga mesa, o dapat ba silang ilagay sa kasalukuyang mga mesa?'
Ikaw, ang developer ng database, sumagot:
“Congratulations, Proprietor! Hindi mo direktang ipinakilala ang isyu ng Third Normal Form.”
Ipagpatuloy mo.
Iba Pang Mga Kinakailangang Hanay
Ang iba pang kinakailangang column ay unang idinagdag sa mga nakaraang talahanayan, na nasa 1NF at 2NF. Binago ang ilan sa mga nakaraang pangalan ng column.
Bilang isang minimum, ang talahanayan ng Mga Kategorya ay dapat magkaroon ng mga sumusunod na hanay:
Mga Kategorya(categoryID, categoryName, paglalarawan)
Ang paglalarawan ay isang maikling talata na naglalarawan sa kategorya. Ang talahanayan ng mga kategorya ay nasa 1NF, 2NF, at 3NF na. Ang 3NF ay ipinaliwanag sa ibaba:
Bilang pinakamababa, ang talahanayan ng Mga Produkto ay dapat magkaroon ng mga sumusunod na column:
Mga Produkto(productID, categoryID, supplierID, productName, unitPrice, quantityInStock, reorderLevel)
Habang ibinebenta ang bawat produkto, maaabot ang mababang antas (bilang) ng mga produkto kapag kailangang muling ayusin ang produkto, kaya hindi dapat pumunta ang mga customer sa tindahan at wala ang produkto. Ang ganitong kawalan ay hindi maganda para sa negosyo. quantityInStock ay ang bilang ng isang partikular na produkto sa stock. Kasama dito kung ano ang nasa tindahan at kung ano ang nasa istante.
categoryID at supplierID ay mga dayuhang key. Kaya naman mayroon silang dash underline sa halip na solong underline. Ipinapaliwanag sa ibaba ang foreign key. Sa nakaraang bahagi ng serye (Second Normal Form), ang categoryID ay bahagi ng pangunahing key na may isang salungguhit dahil sa kung paano ito nakuha. Gayunpaman, mula sa paliwanag sa ibaba, magiging malinaw na ang categoryID ay dapat na isang foreign key (na may dash underline).
Ang talahanayan ng mga produkto na ito ay nasa 1NF, 2NF, at 3NF. Tingnan kung bakit ito ay nasa 3NF sa ibaba:
Bilang pinakamababa, ang talahanayan ng SaleDetails ay dapat magkaroon ng mga sumusunod na column:
Mga Detalye ng Pagbebenta(saleID, productID, unitSellingPrice, dami, diskwento)
Ang halaga ng diskwento ay inaasahang maging zero sa karamihan ng oras. Ang diskwento ay ang diskwento na ibinibigay ng tindahan sa isang customer.
Bilang pinakamababa, ang talahanayan ng OrderDetails ay dapat magkaroon ng mga sumusunod na column:
Mga Detalye ng Order(orderID, productID, unitCostPrice, dami, diskwento)
Ang halaga ng diskwento ay inaasahang maging zero sa karamihan ng oras. Ang discount dito ay ang discount na ibinibigay ng supplier sa shop.
Gaya ng nakikita sa ibaba, ang talahanayan ng Mga Produkto ay maaaring isaalang-alang sa 2NF o 3NF. Ang mga talahanayan ng Sales at Order ay may isyu ng 3NF. Tanging ang Talahanayan ng Pagbebenta ang gagamitin upang ipaliwanag ang isyu at solusyon. Ang 3NF para sa Talahanayan ng Mga Order at Talahanayan ng Mga Produkto ay sumusunod sa magkatulad na pangangatwiran at sisipiin lamang.
Habang nagdaragdag ng mga column, ang talahanayan ng Sales ay magiging:
Benta(saleID, dateSold na customerName, telepono, address, lungsod, rehiyon, postalCode, Bansa, empleyado)
Pinalitan ng pitong column ang column ng customer sa orihinal na talahanayan. Dahil ang mga customer ay mga tao sa kapitbahayan, ang mga cell para sa mga column ng lungsod, rehiyon(estado), postalCode, at bansa, ay maaaring iwanang walang laman, bagama't hindi sila iniwang walang laman sa artikulong ito.
Ang talahanayan ng Sales na ito ay nasa 2NF pa rin dahil parehong hindi nilalabag ang mga panuntunan ng 1NF at 2NF. Gayunpaman, dapat itong matanto na sa isang hilera ng talahanayan ng Pagbebenta, ang customer (pangalan) ay pinalitan ng pitong cell ng hilera ng customer.
Tandaan: ang isang address cell ay may numero ng bahay, pangalan ng kalye o kalsada, at pangalan ng bayan, lahat ay pinaghihiwalay ng mga kuwit. Ang isang lungsod ay maaaring ituring na binubuo ng ilang mga bayan. Bagama't pinaghihiwalay ng mga kuwit ang mga partikular na bahagi ng string na ito, bumubuo sila ng isang cell value at hindi tatlong cell value.
Ang column ng empleyado ay kailangan ding palitan ng pitong ganoong column. Gayunpaman, hindi iyon ginagawa sa tutorial na ito upang makatipid ng oras at espasyo sa pagtuturo. Kaya, ang talahanayan ng Sales na may data ay maaaring:
Talahanayan ng Pagbebenta – 2NF – Nang walang customerID
Ang column ng SaleID na uri ng data ay isang integer o, mas mabuti, auto-increment. Ang uri ng data ng column na dateSold ay isang petsa at hindi isang numero dahil mayroon itong character na '/', na hindi isang digit. Ang uri ng data para sa iba pang column, kabilang ang column ng telepono, ay string (o text). Ang halaga ng telepono ay may karakter na '-', na hindi isang digit.
Tandaan na para sa bawat row, ang customer (pangalan), tulad ng sa nakaraang bahagi ng serye, ay pinalitan ng pitong cell, kung saan ang isa ay customer-name pa rin. Nangangahulugan ito na ang data ng customer ay isang entity. Sa kasalukuyan, kinikilala ng pangalan ng customer ang iba pang anim na data sa isang hilera. Kung naka-program ang talahanayang ito, magiging maginhawang tukuyin ang entity ng customer sa bawat row na may integer (hindi auto-increment). Kung ganoon, dapat na mauna ang isang column ng customerID sa customerName. Ang nakaraang talahanayan ay nagiging:
Talahanayan ng Pagbebenta – 2NF – Sa customerID
May tatlong customerID: 1, 2, at 3, na may 1 na nagaganap nang limang beses para kay John Smith, 2 na nagaganap nang dalawang beses para kay James Taylor, at 3 na nagaganap nang isang beses para kay Susan Wright.
Tandaan na umuulit ang ilang customerID at ang mga depende nito.
Mga Panuntunan para sa Third Normal Form
Ang talahanayan ay nasa Third Normal Form kung ito ay sumusunod sa mga sumusunod na alituntunin:
- Dapat ay nasa Second Normal Form na ito.
- At hindi ito dapat magkaroon ng Transitive Dependency.
Pagkatapos ang isa sa mga klerk (mga empleyado) ay nagtanong, 'Ano ang isang transitive dependency?'. At ikaw, ang developer ng database, ay tumugon, 'Magandang tanong iyon!'
Transitive Dependency
Totoo na sa isang hilera, kinikilala ng SaleID ang lahat ng mga halaga sa row; gayunpaman, tinutukoy ng customerID ang pitong value ng data nito ngunit hindi nito tinutukoy ang iba pang value na tinukoy ng SaleID sa row na iyon. Sa ibang paraan, nakadepende ang SaleID sa sampung cell value sa bawat row. Gayunpaman, nakadepende ang customerID sa pitong cell value sa parehong row, ngunit hindi nakadepende ang customerID sa SaleID at sa iba pang value kung saan nakasalalay ang SaleID.
Ang nasabing dependency para sa custumerID ay transitive dependency. At ang customerID ay tinatawag na foreign key at may salungguhit na gitling sa serye ng tutorial na ito, The Five Normal Forms.
Ipagpalagay na ang isang hindi pangunahing katangian (hindi pangunahing halaga ng cell) ay nakasalalay sa iba pang hindi pangunahing katangian, at ang hindi pangunahing katangian na pinag-uusapan (hal., customerID at mga depende nito) ay hindi nakadepende sa pangunahing susi at sa natitirang bahagi ng cell mga halaga sa hilera. Pagkatapos iyon ay transitive dependency.
Ang nakaraang talahanayan ng Sales na may foreign key at mga depende nito, ay magdudulot ng mga problema sa accounting (mga anomalya).
Talahanayan ng Pagbebenta Mula 2NF hanggang 3NF
Upang malutas ang problemang dulot ng foreign key at ang mga depende nito, alisin ang foreign key at ang mga depende nito, upang bumuo ng bagong table nang walang pag-uulit. Gayunpaman, kahit na ang foreign key ay hindi nakadepende sa primary key, ang primary key ay nakadepende sa foreign key. Kaya, ang isang kopya ng foreign key ay dapat manatili sa parent table. Ang bagong talahanayan ng pagbebenta, sa puntong ito, ay sumusunod sa 1NF, 2NF, at 3NF; ito ay isang parent table. Ang bagong child table mula sa dating Sales table ay sumusunod din sa 1NF, 2NF, at 3NF. Ang pangalan ng child table na may foreign key at mga depende nito, ay Customers. Kung hindi mahanap ang isang angkop na pangalan, may nangyaring mali sa pagsusuri. Ang bagong Talahanayan ng Pagbebenta sa 3NF ay:
Panghuling Talahanayan ng Pagbebenta sa 3NF
Ang talahanayang ito sa 3NF ay may parehong bilang ng mga row gaya ng isa sa 2NF ngunit may mas kaunting mga column.
Ang notasyon ng talahanayan para sa huling talahanayan ng Pagbebenta sa 3NF ay:
Benta(saleID, dateSold, customerID, employeeID)
Ang saleID ay ang pangunahing susi na may isang salungguhit. ang customerID ay isang foreign key, na may gitling na salungguhit. Ang employeeID ay isa ring foreign key na may dash underline. Tandaan na ang sitwasyon ng empleyado sa talahanayan ng Sales sa 2NF ay pareho sa sitwasyon ng customer. Ang employeeID at ang sarili nitong mga nakadepende ay kailangang alisin upang makabuo ng isa pang talahanayan; nananatili ang kopya ng employeeID.
Tandaan: hindi bumubuo ng composite key ang saleID, customerID, at employeeID. nakadepende ang saleID sa customerID at employeeID.
Ang ugnayan sa pagitan ng saleID at customerID ay many-to-one.
Ang talahanayan ng customer sa 3NF
Ang talahanayang ito ay may tatlong row sa halip na 9 na row sa 2NF Sales table. Sa talahanayang ito, ang customerID ay isang pangunahing key. Kapareho ito ng foreign key sa talahanayan ng Sales, ngunit walang pag-uulit. Ang foreign key sa Sales table at ang primary key sa Customer table ay nagli-link sa parehong table.
Ang mga paulit-ulit na row sa talahanayan ng Customer ay inalis upang hindi lumabag sa 1NF.
Tulad ng nakikita ng mambabasa, ang paglalagay ng talahanayan sa 3NF ay malulutas din ang problema ng paulit-ulit na mga hilera (redundancy).
Ang table notation para sa Customers Table ay:
Mga customer(customerID, customerName, telepono, address, lungsod, rehiyon, postCode, bansa)
Muling binisita ang Table ng Mga Produkto
Ang talahanayan ng mga produkto na ibinigay sa itaas sa anyo ng notasyon ay:
Mga Produkto(productID, categoryID, supplierID, productName, unitPrice, quantityInStock, reorderLevel)
Ang pangunahing susi dito ay productID. categoryID at supplierID ay mga dayuhang key. Katulad ng talahanayan ng Customer, mayroong talahanayan ng Mga Kategorya, kung saan ang categoryID ang pangunahing key, at mayroong talahanayan ng Supplier, kung saan ang supplierID ang pangunahing susi.
Kung ang mga halaga para sa mga cell para sa unitPrice, quantityInStock, at reorderLevel ay mananatiling maayos, kung gayon ang talahanayan ng Mga Produkto, kung gayon, ay tunay na nasa 3NF. Kung magbabago ang mga halagang ito, kung gayon ang talahanayan ng Mga Produkto, tulad nito, ay nasa 2NF. Sa bahaging ito ng serye ng tutorial, ipinapalagay na ang mga halagang iyon ay mananatiling maayos sa paglipas ng panahon.
Lahat ng Tables
Ang lahat ng mga talahanayan ay nasa 3NF na ngayon. Ang mga ito ay ipinapakita bilang:
Mga empleyado(employeeID, pangalan, telepono, address, lungsod, rehiyon, postCode, bansa, petsa ng kapanganakan, hireDate, petsaInilabas)
Mga Supplier(supplierID, pangalan, telepono, address, lungsod, rehiyon, postCode, bansa)
Mga Produkto(productID, categoryID, supplierID, productName, unitPrice, quantityInStock, reorderLevel)
Mga Kategorya(categoryID, categoryName, paglalarawan)
Benta(saleID, dateSold, customerID, employeeID)
Mga Detalye ng Pagbebenta(saleID, productID, numberSold, sellingPrice)
Mga customer(customerID, customerName, telepono, address, lungsod, rehiyon, postCode, bansa)
Mga Order(orderID, dateSold, supplierID, employeeID)
Mga Detalye ng Order(orderID, productID, numeroBinili, costPrice)
Hanggang siyam na mga propesyonal na talahanayan ang ginawa mula sa isang talahanayan lamang na ginawa ng mga baguhan upang maiwasan ang redundancy at mga problema sa accounting (mga anomalya mula sa pagpasok, pagtanggal at pag-update). Ang baguhang talahanayan lamang ay hahantong sa mga pagkalugi sa pananalapi.
Pagsubok sa Staff
Sa puntong ito, ang lahat ng empleyado, kabilang ang may-ari, ay dapat na maunawaan ang 1NF, 2NF, at 3NF. Gayunpaman, kailangan nilang masuri. Lahat sila, kasama ang may-ari, ay uupo sa iba't ibang lugar at kukumpleto sa pagsusulit. Ang pagsusulit na binubuo ng isang tanong, ay tatagal ng isang oras, at ito ay ang mga sumusunod:
Tanong: Gamit ang mga panuntunan para sa 1NF, 2NF at 3NF, patunayan na ang lahat ng nasa itaas na siyam na talahanayan ay nasa First Normal Form, Second Normal Form, at Third Normal Form. Ang mga customer at supplier ay hindi kailangang maging tunay na entity. Dapat i-back up ng data para sa mga talahanayan ang mga notasyon ng talahanayan.
Habang kinukumpleto nila ang pagsusulit, ikaw, bilang developer ng database, ay lalabas para kumain ng meryenda at beer, upang bumalik pagkatapos ng isang oras.
Ang Malapit at Malayong Kinabukasan
Habang ikaw, ang developer ng database, ay wala, isinasaalang-alang mo rin kung anong payo ang ibibigay sa kanila kung lahat sila ay pumasa sa pagsusulit.
Gayundin, habang sinasanay mo sila, at ngayon na sila ay kumukuha ng pagsusulit, ang mga customer ay dumarating at umaalis nang hindi inihahatid. Iyan ay hindi mabuti para sa negosyo, at ikaw, ang developer ng database, alam mo iyon. Ang ilang mga customer ay maaaring pumunta sa mga tindahan ng kakumpitensya at hindi na bumalik.
Ikaw, ang developer ng database, ay 30 taong gulang. Ang may-ari, bilang iyong kaibigan, ay 30 taong gulang din. Ang mga klerk (mga empleyado) ay nasa pagitan ng edad na 18 at 24. Ang lahat ng mga katangian na kailangan nila para magtrabaho para sa may-ari ay: malusog, marunong bumasa at sumulat, makapagdagdag, magbawas, magparami, at hatiin. , at upang magamit ang computer at ang Internet.
Kapag ang isang talahanayan ay nasa 3NF, karamihan sa mga kahinaan ay inalis mula sa database. Maraming komersyal na database ang hindi lalampas sa 3NF, at komportable ang mga kumpanya o kumpanya.
Kaya, kung lahat sila ay pumasa sa pagsusulit, hihilingin mo sa mga klerk na pumunta at magpatuloy sa pagtatrabaho. Ipapayo mo rin sa kanila na mag-ipon ng bahagi ng kanilang sahod para magkaroon sila ng kanilang mga convenience shop. Magpapatuloy ka bukas para sanayin ang proprietor lamang sa 4NF at 5NF. Sa kaalaman ng 4NF at 5NF, ang lahat ng kilalang kahinaan ay tinanggal.
Pagsusuri
Pagkatapos ng isang oras, ikaw, ang developer ng database, ay babalik. Markahan mo ang kanilang mga script. Isang piraso ng mahusay na balita! Lahat sila, kasama ang may-ari, ay may 100% bawat isa. Hurray! Iyan ay napakahusay!
Kaya congratulations sa inyong lahat: ang guro at ang mga mag-aaral.
Wala nang magagawa sa tutorial na ito maliban sa tapusin.
Konklusyon
Ang talahanayan ay nasa First Normal Form, kung hindi ito lumalabag sa alinman sa mga sumusunod na panuntunan:
- Ang lahat ng mga column sa isang talahanayan ay dapat may natatanging mga pangalan ng header.
- Ang bawat cell ay dapat magkaroon lamang ng isang halaga.
- Ang mga value na nakaimbak sa isang column ay dapat na pareho ang uri.
- Ang mga hilera ay dapat na naiiba.
- Hindi mahalaga ang pagkakasunud-sunod ng mga column o row.
Ang talahanayan ay nasa Second Normal Form, kung hindi ito lumalabag sa alinman sa mga sumusunod na panuntunan:
- Ang talahanayan ay dapat na nasa First Normal Form.
- Dapat ay walang bahagyang dependency.
Ang talahanayan ay nasa Third Normal Form, kung hindi ito lumalabag sa alinman sa mga sumusunod na panuntunan:
- Dapat ay nasa Second Normal Form na ito.
- At hindi ito dapat magkaroon ng Transitive Dependency.
Ikaw, ang developer ng database, sabihin sa mga klerk na sapat na ang kanilang natutunan. Nagbibigay ka ng payo at hilingin sa kanila na bumalik sa trabaho at manatili sa kanilang mga istasyon bilang default.
Magtakda ka ng appointment sa proprietor lamang, na magaganap sa kanyang opisina bukas para sa pagsasanay sa 4NF at 5NF.
