Oracle SQL & PL / SQL - 8. Data Modeling Database at Disenyo

Posted by admin

Setyembre 23, 2008 500 views

Kapag kami ang gumawa ng database, tayo mangilangan sa maingat na isaalang-alang ang mga sangkap. Para sa mga tagubilin na may kaugnayan sa disenyo, maaari naming sundin ang mga concepts sakop sa diskusyon oras na ito.

System Development Cycle
Database Disenyo
Hamon sa Pamamahala ng Data

8.1. System Development Cycle

Mula sa konsepto sa produksyon, namin bumuo ng isang database na gamit ang sistema ng pag-unlad na cycle. Cycle na ito ay binubuo ng ilang mga yugto ng pag-unlad.

Top-down na diskarte at sistematikong database sa anyo na ito pag-unlad ng mga pangangailangan sa negosyo ng impormasyon sa pagpapatakbo database.

8.1.1. Development yugto

Diskarte at Pagtatasa

Ang pagrerepaso at pagtatasa ng mga pangangailangan sa negosyo. Interview at manager ng mga gumagamit na tukuyin ang impormasyon na pangangailangan. Kombinasyon sa misyon ng kumpanya at ang mga aplikasyon na sistema bilang isang detalye sa hinaharap.
Building sa modelo ng sistema. Maglipat ng mga kuwento na itinayo sa phases sa diskarte at pagtatasa sa isang graphical na representasyon ng mga pangangailangan ng mga negosyo na impormasyon at mga patakaran-aturannya. Kumpirmahin at ang filter modelo sa analysts at eksperto.

Disenyo

Magdisenyo ng isang database. Entity pamanggit modelo sa mapa ang mga nilalang sa mesa, mga katangian sa mga haligi, sa pakikipag-ugnayan sa mga banyagang keys, at negosyo patakaran sa contraints.

Pag-unlad at Documentation

Gumawa ng prototipo sistema. Magsulat at execute ng command na lumikha ng mga mesa at sumusuporta sa mga bagay sa database.
Maghanda ng user documentation, tulong ng screen na teksto, at mga manual na operasyon upang suportahan ang paggamit at pagpapatakbo ng system.

Sa paglipat

Tularan filter. Ang paglipat ng isang aplikasyon sa pagsusuri sa produksyon ng mga user na pagtanggap, ang conversion ng ang data ay umiiral na, at kahilera operasyon.
Gawin ang mga pagbabago na kinakailangan

Produksyon

Ang paglalapat ng sistema sa user. Gumana ang sistema ng produksyon. Ang pagganap, at pagbutihin at filter system.

8.2. Database Disenyo

Relasional disenyo ng isang database system ay nagsasangkot ng proseso ng conversion sa mga modelo ng representasyon sa mga software na maaaring trabaho. Entidad (o mga bagay) na nadama ng mga gumagamit ng transformed sa isang table-table sa database. Sa panahon ng disenyo na proseso, ang aming layunin ay pagdisenyo maaasahang, mataas na pagganap ng mga sistema ng paggamit ng lahat ng mga kaalaman na binuo sa pamamagitan ng lahat ng negosyo na isinasagawa sa pagtatasa ng bahagi. Susi salik ipaliwanag ang mga pangunahing mga sumusunod na detalye sa kung bakit kailangan naming na disenyo ng isang pangalawang ito.

Pagganap

Unang disenyo ng sistema ay isang napaka-malaking impluwensiya sa pagganap dulo. Sa pangkalahatan, ang epekto malayo mas malaki sa pagbuti kapag ang tune system ay tumatakbo.

Integrated mga Aplikasyon
Sistema ng mga aplikasyon ay karaniwang binuo sa pamamagitan ng mga developer. Walang ng ilan sa mga disenyo ng mga detalye ng kung paano gumagana ang sistema, ang bawat developer ay magtatayo ang estilo ng kanilang mga sarili. Ang isang magandang disenyo ay hindi lamang ng mga kapaki-pakinabang upang madagdagan ang hitsura at pakiramdam, ngunit din na ang bawat bahagi menyakinkan ang application ng sistema nakapaloob sa bawat isa.

Integration sa Iba Pang Systems

Kadalasan ay may kinakailangan na ang bagong sistema ay nakapaloob sa mga sistema na doon, o kahit sa iba pang mga sistema na lamang binuo. Disenyo ay mabuti upang madagdagan ang benepisyo ng integration na inilarawan sa itaas sa sistema sa pangkalahatan.

Babasahin at Komunikasyon

Ang mga pangunahing bahagi ng gawain ng isang disenyo ay makipag-usap disenyo ng mga desisyon ng iba. Sa katapusan, ang mga desisyon na kailangan dokumentado.

Scalability

Mutya ng pagganap ng mga isyu kapag inihambing sa ang disenyo sa oras ng produksyon. Halimbawa, upang bumuo ng sistema sa kapaligiran ng mga maliliit at walang kinokontrol ng isang pagsubok sa sitwasyon o sa katunayan, sa isang malaking koleksyon ng data, ang mga kadahilanan na maaaring ibunyag defects sa disenyo-bantot.

Iwasan Maghanap Bumalik Wheel

Marami sa mga problema na maaaring matagpo ay na natagpuan ng isang tao na bago sa amin. Gumamit ng isang disenyo na ito ay matagumpay na bago kung maaari.

8.2.1. Data Modelo

Modelo ay ang batayan ng disenyo. Ang mga inhinyero bumuo ng isang modelo ng sasakyan at memproduksinya bago gumawa ng anumang detalyadong trabaho sa. Sa parehong paraan, ang sistema ng designer bumuo ng modelo ng galugarin ang mga ideya at dagdagan-unawa sa mga disenyo ng database.

8.2.1.1. Gamitin ang Layunin Modelo

Modelo sa tulong makipag-usap sa mga konsepto ng mga tao ang isip. Modelo ay maaaring gamitin para sa mga layunin ng mga sumusunod:

Makipag-usap
Subsume
Ilarawan
Itakda
Suriin
Maghanda
Nagtatasa
Magpanggap

Ang target ay ang mga nararapat na modelo para sa maraming mga gumagamit, ay maaaring maunawaan sa pamamagitan ng lahat ng mga gumagamit, ngunit ang mga detalye ay sapat na para sa mga developer na bumuo ng isang database system.

8.3. Entity Relationship Modeling

Entity relasyon modelo nagmula sa mga detalye o negosyo kuwento. Ang modelo ay ang isang graphical representation ng mga pangangailangan ng mga negosyo na impormasyon at mga patakaran-aturannya.

Entity relasyon modelo sa hiwalay na mga impormasyon na kailangan ng mga negosyo sa mga gawain na ibinibigay sa pamamagitan ng negosyo. Kahit na negosyo mong baguhin ang mga gawain, i-type ang mga impormasyon tends to hold pa rin. Samakatuwid, ang mga istruktura ng data na rin madalas na hold pa rin.

8.3.1. Benepisyo Entity Relationship Modelo

Documenting ang mga pangangailangan ng kumpanya na impormasyon sa isang format na malinaw at tiyak
Magbigay ng isang mapa ng imahe na ito ay madaling maunawaan upang magdisenyo ng isang database
Paunlarin at madaling filter modelo
Magbigay ng isang malinaw na larawan tungkol sa coverage ng mga pangangailangan ng mga impormasyon
Ay nag-aalok ng isang mabisang balangkas upang magbuo ng maramihang mga aplikasyon, ang pag-unlad sa proyekto, at ang pagbili ng mga aplikasyon na pakete

8.3.2. Key Components

Entity Relationship Modelo binubuo ng mga nilalang, katangian, at ang relasyon

Entity
- Isang bagay na mahalaga ang tungkol sa mga pangangailangan ng mga impormasyon dmana tandaan. Entity ay kumakatawan sa isang bagay na mahalaga mula sa isang negosyo na sistema, o ang kategorya o mga koleksyon ng data na may kinalaman sa bawat isa. Halimbawa ay customer, ayos, at ang mga empleyado. Para sa mga entidad na kumakatawan sa mga modelo, maaari naming gamitin ang mga sumusunod na probisyon:
  - Na kahon na may partikular na laki
  - Pangalan ng isang nilalang at natatanging
  - Pangalan sa kapital na titik entidad
  - Synonym pangalan sa kapital na titik opsyonal diapit sign "()"
Attribute
- At ipaliwanag ang isang bagay na nangangailangan ng isang nilalang. Attribute at ang mga nilalang na humahawak sa mga tiyak na impormasyon na dapat ay alam na ang tungkol sa isang nilalang. Halimbawa, ang mga nilalang para sa mga customer, attribute na ito ay maaaring maging isang customer number, pangalan, numero ng telepono, at address. Kung ang isang nilalang ay hindi may ang katangian na dapat mula sa isang negosyo perspektibo, siya ay hindi sa hanay ng mga pangangailangan ng sistema, at ito ay hindi dapat lalabas sa modelo. Ang bawat katangian ay maaaring maging kasing sapilitan (sapilitan) at opsyonal. Ang kundisyong ito ay tinatawag na denan opsionalitas (optionality). Attribute upang kumatawan sa mga modelo, maaari naming gamitin ang mga sumusunod na probisyon:
  - Gamitin ang isang pangalan sa mga maliliit na titik
  - Kilalanin ang mga kinakailangang katangian, o ang halaga na dapat na minarkahan ng "*"
  - Kilalanin ang opsiyonal na katangian (hindi sapilitan) sa mga mag-sign "o"
Relasyon
- Relasyon sa pagitan ng mga entity o ang opsionalitas degrees. Ang bawat nilalang ay dapat magkaroon ng isang relasyon na kumakatawan sa mga pangangailangan ng mga impormasyon at sa mga patakaran ng negosyo. Relasyon ay isang dalawang-daan na relasyon sa pagitan ng dalawang nilalang, o ang entidad sa kanyang sarili. Kapag ang isang nilalang ay may relasyon na may kaugnayan sa kanyang sarili, ito ay tinatawag na recursive.
- Syntax Relationship
  - Ang bawat source entidad [ay maaaring | ay dapat] relasyon pangalan [isa at isa lamang | ang isa o higit pa] patutunguhang entidad
  - Tandaan: Ang Batas ay read clockwise
- Patakarang Relationship Diagram
  - Dashed linya (-)
    - Opsyonal na sangkap na nagpapahiwatig ng "ay maaring maging"
  - Solid linya (-)
    - Sapilitang elemento ng "ay dapat"
  - Himpilan ng paa (uwak piye)
    - Mga elemento ng antas ng "isa o higit pang mga"
  - Iisang linya (-)
    - Mga elemento ng antas ng "isa at isa lamang"
- Recursive Relationship
  - Relasyon sa pagitan ng mga nilalang na tinatawag na recursive sarili at relasyon. Kinakatawan ng mga "baboy's tainga" (baboy tainga).
- Uri ng Relasyon
  - Isa-sa-isang
    - Degrees isa at isa lamang sa parehong direksyon. Ang ganitong uri ng bukod-tangi, at maaaring talaga ay ang parehong nilalang, o mga katangian ng mga nilalang. Halimbawa: Relations sa pagitan ng asawa at asawa.
  - Maraming-sa-isang
    - Ng isa o higit pang mga degree sa isang direksyon at isang degree at isa lamang sa ibang direksyon. Ito ay isang napaka-pangkaraniwan uri. Halimbawa: Relations sa pagitan ng mga pasahero at mga sasakyang panghimpapawid.
  - Maraming-to-maraming
    - Ng isa o higit pang mga degree sa parehong direksyon. Ito ay isang napaka-pangkaraniwan uri. Halimbawa: Relations sa pagitan ng mga kawani at kadalubhasaan.
UID (unique identifier)
- Natatanging identifier ay isang kumbinasyon ng mga katangian o relasyon, o pareho, na function bilang pembeda penampakan mula sa bawat nilalang. Penampakan ng bawat nilalang ay dapat na natatangi ay kinilala.
  - Kumuha na malaman ang bawat katangian na bahagi ng UID sa mga simbolo ng numero (#)
  - Kumuha na malaman ang UID ng ikalawang numero sa pamamagitan ng paggamit ng mga simbolo na diapit solong quotes ('#')
- Sa pamamagitan ng mga natatanging identifier Relationship
  Ng isang nilalang ay makikilala sa pamamagitan ng isang natatanging relasyon. Gamitin UID bar upang ipahiwatig na ang isang relasyon ay bahagi ng natatanging identifier na entidad. Relasyon ay kasama sa UID ay dapat na magkaroon ng sapilitan at isa lamang sa mga relasyon ng mga kalahok sa UID.
  - Halimbawa kapag kami ay mga order sa pamimili, kami ay ang pagkakasunod-sunod na numero at linya ng mga item na may mga natatanging bagay na numero. Ngunit kapag ang iba pang mga pagbili-order ay nagawa na, ang bagay na numero ay hindi na kakaiba. Samakatuwid, ang mga bagay na kinilala sa pamamagitan ng isang natatanging katangian sa kanyang numero at order number kung saan ang isang partikular na item berelasi.
  Order number, item number, numero ng Produkto
  100, 1, 209
  100, 2, 399
  100, 3, 876
  101, 1, 630
  101, 2, 297

8.4. Normalisasyon

Bago ang paglikha ng isang database disenyo, kami ay dapat na-minimize ang mga problema ng mga data sa pamamagitan ng kalabisan normalisasyon ng data modelo. Kailangan naming baguhin ang data ng modelo na sumusuporta sa mga pangangailangan sa pagganap ng iba't-ibang disenyo at baguhin ang database na may data storage normalisasyon bago tayo gumawa ng database.

8.4.1. Benepisyo normalisasyon

Minimize ng data sasalita
Bawasan ang mga problema ng integridad
Kilalanin ang mga nilalang, relasyon, at ang mga talahanayan terlewatkan

8.4.2. Normalisasyon patakaran

Unang normal form (1NF)
- Ang lahat ng katangian na halaga ay dapat na nag-iisang at hindi paulit-ulit na
Pangalawang normal form (2NF)
- Ang bawat katangian ay dapat nakabatay sa lahat ng mga natatanging identifier (UID) nilalang sa kanyang
Ikatlong normal form (3NF)
- Diyan ay hindi maaaring walang-UID na nakabatay sa ibang di-UID

8.5. Integridad at pagpilit Key

Siguraduhin na ang mga gumagamit lamang sa mga operasyon na payagan ang mga database ay pabagu-bago ang mga pangyayari na nag-apply ang integridad pagpilit. Ang lahat ng mga data integridad pagpilit ay dapat mailapat ng database server o software ng application. Key (ang susi) ay maaaring equated sa ang integridad pagpilit. Tatlong uri ng mga pangunahing susi ay ang susi, naiibang susi, at banyagang key.

8.5.1. Uri ng Integrity pagpilit

Entity
- Diyan ay hindi dapat maging bahagi ng pangunahing susi ay NULL, at ang halaga ay dapat na natatanging (mula sa iba't-ibang ang isa sa iba pa)
Referential
- Mga halaga ng mga banyagang susi ay dapat na alinsunod sa mga pangunahing susi halaga na diacunya, o NULL
Haligi
- Halaga sa haligi ay dapat na alinsunod sa mga uri ng data na ito ay natukoy para sa mga haligi ay
Na tinukoy ng gumagamit
- Mga halagang ito ay dapat na napapailalim sa mga patakaran ng negosyo (business patakaran)

8.5.2. Uri ng susi

Pangunahing Key
Ang bawat hilera (record) sa talahanayan ay makikilala sa pamamagitan ng mga natatanging haligi o hanay ng mga haligi na tinatawag na ang mga pangunahing key (PK). Pangunahing susi ay hindi tinukoy na pahintulutan ang halaga ng mga dobleng at hindi maaaring NULL halaga.
Pangunahing susi na binubuo ng ilang mga haligi na tinatawag composite pangunahing susi o tambalan pangunahing key. Haligi-column ng composite pangunahing susi ay dapat na natatangi sa mga kumbinasyon, kahit na ang halaga ng mga indibidwal na maaaring magkaroon ng isang dobleng. Walang bahagi ng mga pangunahing susi ay maaaring magkaroon ng isang NULL halaga.
Kandidato Key
Ang isang talahanayan ay maaaring magkaroon ng maramihang mga kandidato keys. Kandidato susi ay isang haligi o kumbinasyon ng haligi na maaaring function bilang isang pangunahing susi para sa mga mesa.
Pumili ng isang susi kandidato upang maglingkod bilang ang pangunahing susi sa mesa. Kandidato ay ang iba pang mga susi ng alternatibong mga susi o natatanging key. Sila ay dapat natatanging at HINDI NULL.
Dayuhang Key
Dayuhang key (FK) ay isang haligi o ng isang kumbinasyon ng isang haligi sa talahanayan sumangguni sa pangunahing susi o natatanging susi sa parehong mesa o sa iba pang mga mesa. Dayuhang key batay sa halaga ng data at pulos logical, at hindi isang pisikal na puntero. Ang halaga ng isang dayuhan na key ay dapat na alinsunod sa mga pangunahing susi o natatanging susi ay diacunya, o maaaring NULL. Kung ang isang dayuhan na key ay isang mahalagang bahagi ng pangunahing, siya ay hindi maaaring maglaman ng null halaga dahil maaaring walang bahagi ng pangunahing susi halaga NULL. Halimbawa: Sa ang bagay na mesa, haligi ORD_ID ay hindi maaaring maglaman ng null halaga na ito sapagkat ito ay bahagi ng pangunahing key.

8.6. Disenyo Database

Ang yugto sa disenyo ng database-disenyo ng mga tiyak na detalye para sa pamanggit database, kasama na ang mga kahulugan para sa mga talahanayan, index, tingnan, at espasyo sa imbakan.

8.6.1. Mapping Entity Relationship Modelo sa Table pagkakataon Tsart

Mapping Entity sa Talaan
Lumikha ng isang talahanayan na pagkakataon chart para sa bagong mesa. Mesa halimbawa ng tsart ay dapat maglaman ng isang haligi sa talahanayan ng mga pangalan, haligi pangalan, key uri, null at natatanging, banyagang key impormasyon, haligi datatype, at maximum na haba, at sample na data. I-save ang pangalan tablenya.
Mapping attribute sa Haligi
Mapa ng bawat attribute sa mga entidad na relasyon modelo sa haligi sa talahanayan, magdagdag ng data sa chart ng isang halimbawa upang ipakita ang mga nilalaman ng mesa sa visual format. Sapilitan attribute mapa, na minarkahan ng asterisk (*), upang ang mga haligi na ito ay tinukoy bilang HINDI NULL (NN).
Huwag pangalan ang haligi sa SQL reserved salita, tulad ng NUMBER. Bigyan ng pangalan ng haligi sa pagpapaikli stands-pare-pareho, tulad ng HINDI o mga NUM (ngunit hindi pareho) upang maiwasan ang pagkalito programmer at gumagamit.
Mapping unique identifier sa Pangunahing Key
UID mapa na ito ay makikilala sa mga entidad na may kaugnayan modelo ang bilang simbolo (#) sa pangunahing haligi ng susi, at markahan ang mga ito bilang mga susi PK. UID mapa na naglalaman ng isang solong attribute sa mga single-haligi PK. Markahan ang hindi null at natatanging may NN at U. UID mapa na naglalaman ng maraming mga katangian sa composite PK. Markahan ang mga haligi sa mga haligi-NN at U1. Kung may isang pangunahing susi alternatibo, markahan sa NN at U, ngunit pumili lamang ng isa PK.
Kung UID sa relasyon (ipinahiwatig sa pamamagitan ng UID bar), idagdag ang isang haligi para sa bawat FK relasyon at markahan sa PK at FK. Magdagdag ng haligi-haligi FK pagkakataon sa dulo ng table o tsart sa kanang bahagi ng buong haligi, kahit FK ay bahagi ng PK. Pumili ng isang natatanging pangalan para sa bawat FK haligi at magdagdag ng sample na data.
Paggawa ng mga mapa sa Foreign Key Relationship
Ang huling hakbang ay ang mapa ng mga banyagang key relasyon. Mayroong dalawang mga uri ng mga relasyon sa nota: Maraming-sa-isa at isa-sa-isa. Kung ang isang relasyon ay bahagi ng UID, pagkatapos na namin memetakannya. Siguraduhin na ang aming relasyon sa markahan sapilitan NN. Pumili ng isang natatanging pangalan para sa mga banyagang susi ay columnt.
- Maraming-sa-isang Relasyon
  Mapa ng maraming-sa-isang relasyon na may isang pangunahing susi sa paglalagay ng "isa" at ilagay ang mga banyagang susi sa "maraming". Diskarteng ito ay maaari ding magamit para sa recursive relasyon.
- Isa-sa-isang Opsyonal Relationship
  Kami ay maaaring ilagay sa isang banyaga ang susi na relasyon sa isang bahagi ng ganitong uri ng relasyon. Siguraduhin na idagdag ang U.
- Isa-sa-isang Relationship sapilitan
  Ilagay ang mga natatanging dayuhang susi sa gilid na mesa at sapilitan markahan sa NN na magpataw ng sapilitan at U na kailangang magpataw ng isa-sa-isang relasyon.

8.6.2. Karagdagang mga pangangailangan

Disenyo ng indeks, kung saan ang mga object ay isang database na nagbibigay ng mabilis at direktang access sa mga hilera sa talahanayan. Maaari din naming kailangan upang malikha ang index para sa alternatibong susi, banyagang key, at ang haligi-haligi na kung saan ay madalas na ginagamit sa mga kondisyon ng paghahanap ng data.
Malaman ang kahulugan ng view, na kung saan ay isang lohikal na mesa base sa isa o higit pa sa mesa o tingnan. Tingnan ang hangganan ay maaaring ma-access, upang mapagbuti ang mga pagtatanghal ng mga impormasyon, at maaaring maglaman ng mga komplikadong mga tanong na nabuo na noon.
Plano sa pisikal na storage space, kung saan ay ang kabuuang halaga ng puwang na kinakailangan upang makapag-imbak ng data mula sa isang table sa database.
Meredefinisikan integridad pagpilit

8.6.3. Mga simbolo sa dokumento Talaan pagkakataon Tsart

PK
- Pangunahing susi
FK
- Dayuhang susi
FK1, FK2
- Dalawang banyagang key mesa sa parehong
FK1, FK1
- Composite ng dalawang haligi sa parehong dayuhan susi
NN
- Hindi null
U
- Natatanging
U1, U2
- Dalawang haligi sa natatanging kombinasyon

8.6.4. Patnubay

Pangalan ng mesa ay dapat madaling sinusubaybayan sa nilalang na ang pangalan nito. Pangalan ng maramihan entidad kung minsan ginagamit dahil ito ay naglalaman ng isang pulutong ng mga mesa hilera.
Pangalan ng haligi na dapat ay madaling masusubaybayan nang pabalik sa entidad relasyon modelo. Pangalan ng maikling haligi ay bawasan ang oras na kailangan sa pag-parse ng SQL command.
Kami ay dapat na bumuo ng kanyang sariling mga patakaran para sa pagbibigay at default.

Mangyari lamang na magpatuloy sa pagbabasa ng mga diskusyon Paggawa ng Talaan

Tandaan:
Pagsasanay sa mga artikulo tungkol sa Oracle SQL & PL / SQL script maaari mong i-download ang mesa dito, at tumakbo sa live demo (ang iyong browser ay dapat na suporta ng Flash Player).

Oracle SQL & PL / SQL

Maaari kang tumulong sa mga site na ito na magbigay ng donasyon sa amin. Anuman ang halaga na ito ay tunay mahalaga sa amin. Distributes donasyon pahina sa pamamagitan ng inyong donations. Salamat.