Pagmomodelo ng Datos: Mga Teknik, Uri at Gamit sa Tunay na Mundo na Ipinaliwanag

Tahanan » Python » Pagmomodelo ng Datos: Mga Teknik, Uri at Paliwanag sa mga Gamit sa Tunay na Mundo

Ang data modeling ay isa sa mga disiplinang tahimik na nagpapasya kung ang iyong mga proyekto sa data ay matagumpay o hindi . Sa likod ng bawat analytics dashboard, transactional system, o BI solution, mayroong isang data model na naglalarawan kung anong data ang umiiral, kung paano ito konektado, at kung paano ito gagamitin sa araw-araw. Kapag ang modelong iyon ay malinaw at mahusay na dinisenyo, mas madali ang pagbuo, maaasahan ang mga ulat, at lahat ay nagsasalita ng parehong wika tungkol sa negosyo.

Sa kaibuturan nito, ang isang modelo ng datos ay isang pormal at biswal na paraan upang ilarawan ang impormasyon ng negosyo : kung anong mga entidad ang umiiral (mga customer, produkto, bodega, invoice…), kung aling mga katangian ang tumutukoy sa mga ito (pangalan, address, kapasidad, presyo…), at kung paano sila nauugnay sa isa't isa. Iba't ibang mga diskarte sa pagmomodelo at mga uri ng modelo ang umunlad sa paglipas ng mga taon, na hinimok ng mga bagong teknolohiya sa database, mga pangangailangan sa pamamahala, at mga modernong kaso ng paggamit ng analytics tulad ng Business Intelligence (BI) at data warehousing.

Ano ang isang modelo ng datos?

Ang isang modelo ng datos ay isang abstraktong blueprint kung paano nakabalangkas ang impormasyon sa loob ng isang sistema . Tinutukoy nito ang mga elemento ng datos, ang mga patakarang namamahala sa mga ito, at ang mga ugnayang nagbubuklod sa mga ito, bago pa man aktwal na ipatupad ang anumang bagay sa isang database o aplikasyon. Isipin ito bilang planong arkitektura na sinusunod ng isang inhinyero bago ibuhos ang kongkreto.

Sa praktikal na termino, ipinapakita ng isang modelo ng datos kung paano iniimbak, kinokonekta, ina-access, at ina-update ang datos sa loob ng isang sistema ng pamamahala ng database. Gamit ang mga simbolo, kahon, linya, at teksto, binibigyan nito ang mga stakeholder ng negosyo, analyst, arkitekto, at developer ng isang ibinahaging larawan ng impormasyong pinapahalagahan ng organisasyon, upang ang lahat ay makapagpaliwanag tungkol dito at matukoy ang mga isyu nang maaga.

Isa sa mga pangunahing layunin ng isang modelo ng datos ay ang linawin ang mga uri ng datos na ginagamit at nakaimbak sa sistema , kung paano nagsasama-sama ang mga uring iyon, kung paano sila maaaring isaayos sa mga istruktura, at kung aling mga format at katangian ang taglay ng mga ito. Kabilang dito ang pagtukoy sa mga susi, mga limitasyon, mga kardinalidad, at mga kumbensyon sa pagpapangalan na siyang magtutulak sa teknikal na implementasyon sa hinaharap.

Ang mga modelo ng datos ay hindi nalilikha nang walang kontrol; ang mga ito ay hinihimok ng mga kinakailangan ng negosyo . Bago magsimula ang pagmomodelo, ang mga patakaran at pangangailangan ay tinitipon mula sa mga stakeholder ng negosyo at mga end user. Ang mga patakarang iyon ay isinasalin sa mga istruktura ng datos na humuhubog sa disenyo ng isang bagong sistema o sa ebolusyon ng isang umiiral na. Sa ganitong diwa, ang isang modelo ng datos ay halos kapareho ng isang roadmap: wala itong isinasagawa, ngunit sinasabi nito sa iyo kung paano makarating mula A patungong B.

Ang mahusay na pagmomodelo ng datos ay nakasalalay sa mga istandardisadong iskema at pormal na pamamaraan . Ang istandardisasyong ito ay nagbibigay ng isang pare-pareho at mahuhulaang paraan upang tukuyin at pamahalaan ang mga mapagkukunan ng datos sa mga koponan, departamento, at maging sa mga panlabas na kasosyo. Sa isip, ang mga modelo ay nagiging mga buhay na dokumento na nagbabago habang nagbabago ang organisasyon, na sumusuporta sa pagpapabuti ng proseso at gumagabay sa mga desisyon sa arkitektura ng IT.

Ano ang pagmomodelo ng datos?

Ang data modeling ay ang proseso ng pagmamapa at pag-visualize kung saan naninirahan ang data at kung paano ito dumadaloy sa isang sistema . Tinutukoy mo ang lahat ng lugar kung saan mag-iimbak ng impormasyon ang isang application, integration, o BI platform, pagkatapos ay ididisenyo kung paano kumokonekta at nakikipag-ugnayan ang mga data set na iyon.

Sa loob ng anumang proyekto sa IT, ang pagmomodelo ng datos ay isang kritikal na yugto ng disenyo . Habang ang solusyon ay nasa drawing board pa lamang, tinutukoy ng pangkat kung aling mga problema sa negosyo ang dapat lutasin, kung aling datos ang kinakailangan upang matugunan ang mga problemang iyon, at kung paano gagamitin ng mga gumagamit at iba pang mga sistema ang datos na iyon. Ang pag-unawang iyon ay ginagawa pang mga diagram na naglalarawan kung paano nauugnay at gumagalaw ang iba't ibang grupo ng datos sa pagitan ng mga bahagi.

Ang resulta ng pagmomodelo ng datos ay karaniwang isa o higit pang mga diagram (o modelo) na naglalarawan kung paano nauugnay ang bawat pangkat ng datos sa iba . Maaari itong maging mga konseptwal na diagram para sa mga tagapakinig ng negosyo, mga lohikal na modelo na nagpapakita ng mga istruktura at ugnayan nang mas detalyado, o mga pisikal na modelo na direktang nakatali sa mga talahanayan at kolum ng database. Ang bawat antas ng abstraksyon ay nagpapabuti sa nauna, na papalapit sa implementasyon.

Maaaring imodelo ang datos sa iba't ibang antas ng abstraksyon, mula sa mga konseptong napakataas ang antas hanggang sa mga detalyadong iskema . Ang siklo ng buhay ng pagmomodelo ay karaniwang nagsisimula sa pag-unawa sa mga kinakailangan ng stakeholder, pag-convert ng mga patakaran sa negosyo sa mga istruktura ng datos, at pagkatapos ay pagpino ng mga istrukturang iyon sa isang konkretong disenyo ng database. Sa proseso, ang mga kakulangan, hindi pagkakapare-pareho, o nawawalang mga elemento ng datos ay nagiging nakikita at maaaring maayos bago pa man maging mga isyu sa produksyon.

Dahil nagbabago ang mga kinakailangan, ang mga modelo ng datos ay dapat ituring bilang mga buhay na artifact . Binabalikan ang mga ito tuwing may mga bagong tampok na idinaragdag, lumilitaw ang mga integrasyon, nagbabago ang mga regulasyon o lumilitaw ang mga bagong pangangailangan sa analytics. Maaari pang ipagpalit ang mga ibinahaging modelo sa mga supplier at kasosyo upang ihanay kung paano nauunawaan at ipinagpapalit ang datos sa iba't ibang organisasyon.

Mga pangunahing pamamaraan sa pagmomodelo ng datos at mga uri ng modelo

Sa paglipas ng panahon, lumitaw ang iba't ibang pamamaraan ng pagmomodelo ng datos, bawat isa ay na-optimize para sa mga partikular na teknolohiya at mga kaso ng paggamit . Mula sa mga unang hierarchical database hanggang sa mga modernong dimensional at associative na pamamaraan na ginagamit sa BI, ang bawat istilo ay nag-aalok ng mga partikular na kalakasan at mga trade-off sa mga tuntunin ng kakayahang umangkop, pagganap at kadalian ng pag-unawa.

Sa ibaba ay makikita mo ang isang malalimang paglilibot sa mga pinakamahalagang uri ng modelo ng datos , na inilalarawan gamit ang mga konkretong halimbawa tulad ng mga dealership ng kotse, bodega at BI star schema, at ipinaliwanag sa wikang madaling gamitin sa negosyo upang masundan ng parehong teknikal at di-teknikal na mga mambabasa.

Pagmomodelo ng hierarchical data

Ang hierarchical data model ay nag-oorganisa ng impormasyon sa isang istrukturang parang puno , na may iisang ugat sa itaas at maraming antas ng mga child node sa ilalim nito. Ang bawat parent node ay maaaring magkaroon ng maraming child, ngunit ang bawat child ay may eksaktong isang magulang, na nagreresulta sa isang mahigpit na one-to-many relationship pattern.

Sa pamamaraang ito, ang mga ugnayan ay isinasagawa sa iisang landas mula sa magulang patungo sa anak . Walang konsepto ng isang rekord na may maraming magulang. Ang mga pointer (o link) ay nagkokonekta sa mga magulang sa kanilang mga anak, at tinatahak mo ang mga pointer na iyon upang ma-access o ma-update ang data. Dahil ang bawat rekord ay nasa isang tinukoy na lugar sa puno, madaling mangatwiran tungkol sa pinagmulan nito.

Isaalang-alang ang isang halimbawa ng isang car dealership : ang isang top-level node ay maaaring kumatawan sa "Mga Showroom". Ang bawat showroom node ay magkakaroon ng mga child node para sa "Mga Kotse" at "Mga Salespeople", dahil ang isang showroom ay maaaring mag-host ng maraming kotse at mag-empleyo ng maraming salespeople. Ang nabigasyon ay palaging magsisimula sa showroom at bababa upang makita kung aling mga kotse at sales staff ang kabilang dito.

Mahusay ang mga hierarchical model kapag ang iyong totoong istruktura ay natural na hugis puno , tulad ng mga sitemap ng website, mga organizational chart, mga breakdown ng recipe, o mga kategorya ng produkto sa isang e-commerce site. Halimbawa, ang "Shoes" ay maaaring ang parent category, na may mga child node tulad ng "Women's Shoes" at "Men's Shoes", at mga karagdagang children tulad ng "Sneakers", "Heels" o "Boots".

Ang istilo na ito ay may ilang malinaw na katangian at limitasyon : ang mga ugnayan ay mahigpit na one-to-many, isang landas lamang ang makukuha mo mula sa ugat patungo sa anumang anak, at ang pagbura ng isang magulang ay karaniwang awtomatikong nag-aalis ng lahat ng mga anak nito. Ang sunod-sunod na pagbura na iyon ay maaaring maging maginhawa, ngunit mapanganib din kung hindi ka maingat sa semantika ng iyong hierarchy.

Pagmomodelo ng datos ng network

Pinalalawak ng modelo ng datos ng network ang hierarchical na pamamaraan sa pamamagitan ng pagpapahintulot sa mga talaan na magkaroon ng maraming magulang . Sa halip na isang purong puno, magtatapos ka sa isang mala-graph na network ng mga magkakaugnay na talaan, tulad ng mga database ng pinamamahalaang graph , na ginagawang mas madaling kumatawan sa mga kumplikadong sitwasyon sa totoong mundo.

Sa isang modelo ng network, mas maraming pattern ng relasyon ang posible . Hindi lang isa-sa-marami ang maaari mong pangasiwaan, kundi pati na rin ang isa-sa-isa at marami-sa-marami na mga relasyon. Ang mga node ay maaaring konektado sa pamamagitan ng maraming ruta, na nangangahulugang maaaring mayroong ilang mga paraan upang maabot ang parehong record kapag nagna-navigate sa istruktura.

Isipin ang isang estudyanteng kabilang sa departamento ng Computer Science ngunit mayroon ding mga karapatan sa paghiram sa library . Sa isang network model, ang rekord na "Estudyante" na iyon ay maaaring magkaroon ng dalawang rekord ng magulang: isa para sa "CSE Department" at isa pa para sa "Library". Imposible ito sa isang mahigpit na hierarchical tree kung saan ang isang bata ay maaari lamang magkaroon ng iisang magulang.

Ang mga pinagbabatayang operasyon sa mga modelo ng network ay kadalasang ipinapatupad gamit ang mga pabilog na naka-link na listahan . Sinusubaybayan ng isang programa ang isang "kasalukuyang posisyon" sa listahang iyon at gumagalaw sa mga konektadong talaan ayon sa mga tinukoy na relasyon. Ginagawa nitong mabilis at nababaluktot ang mga traversal, dahil maaari mong sundan ang maraming posibleng ruta patungo sa parehong piraso ng data.

Dahil sa mas mataas na koneksyon, ang mga modelo ng network ay maaaring kumatawan sa mas detalyado at totoong mga ugnayan , ngunit nagiging mas kumplikado rin ang mga ito upang maunawaan at pamahalaan. Ang pagdidisenyo at pagpapanatili ng lahat ng mga link ay maaaring maging mahirap, lalo na para sa malalaking iskema at umuusbong na mga patakaran sa negosyo.

Pagmomodelo ng datos ng Entidad-Relasyon (ER)

Ang modelo ng Entity-Relationship ay isang mataas na antas, biswal na paraan upang ilarawan ang mga kinakailangan sa datos gamit ang mga ER diagram . Isa ito sa mga pinakamalawak na ginagamit na pamamaraan para sa konseptwal at lohikal na pagmomodelo ng datos, lalo na kapag nakikipagtulungan sa mga stakeholder ng negosyo na nangangailangan ng malinaw na larawan nang walang teknikal na kalat.

Sa isang ER diagram, ang mga pangunahing bloke ng pagbuo ay mga entity, katangian, at mga ugnayan . Ang mga entity ay kumakatawan sa mga totoong bagay na pinapahalagahan ng negosyo (tulad ng "Estudyante", "Guro", "Kurso" o "Departamento"). Kinukuha ng mga katangian ang mga katangian ng mga entity na iyon (tulad ng ID ng guro, suweldo, edad), at ipinapakita ng mga ugnayan kung paano konektado ang mga entity (halimbawa, ang isang "Guro ay nagtatrabaho para sa Departamento").

Ang mga entity ay karaniwang iginuguhit bilang mga parihaba, ang mga attribute bilang mga oval, at ang mga relasyon bilang mga diamante o mga linyang may label . Ang mga cardinality (tulad ng one-to-many o many-to-many) ay nagpapahiwatig kung gaano karaming mga pagkakataon ng bawat entity ang maaaring pag-ugnayin. Ang notasyong ito ay nagbibigay-daan sa iyong makuha ang mga kumplikadong panuntunan sa isang diagram na medyo madali pa ring basahin.

Gumagamit ang mga data architect ng mga ER tool upang idisenyo at pinuhin ang mga modelong ito . Sa maraming pagkakataon, ang mga ER diagram ay nagiging tulay sa pagitan ng pagsusuri ng negosyo at pagpapatupad ng database: kapag napagkasunduan na ang modelo ng ER, maaari itong baguhin sa mga relational table, key, at constraint sa isang sistematikong paraan.

Dahil ang ER modeling ay gumagana sa medyo mataas na antas ng abstraksyon , ito ay mahusay para sa pagpapatunay ng pag-unawa sa mga stakeholder. Maaari mong suriin ang diagram sa mga workshop, tanungin kung mayroon nang lahat ng kinakailangang entidad at ugnayan, at ayusin ang disenyo bago lumipat sa mas teknikal na mga layer.

Pagmomodelo ng datos na may kaugnayan

Ang relational model ang gulugod ng karamihan sa mga tradisyonal na sistema ng database . Dito, ang data ay nakaimbak sa mga two-dimensional na talahanayan na binubuo ng mga hilera at hanay, at ang mga ugnayan sa pagitan ng mga talahanayan ay ipinapahayag sa pamamagitan ng mga susi, hindi sa pamamagitan ng mga tahasang pointer tulad ng sa mga hierarchical o network model.

Ang bawat talahanayan sa isang relational model ay madalas na tinatawag na "relation" , bagama't sa pagsasagawa ay maririnig mo ang mga tao na tinutukoy lamang ang mga ito bilang mga talahanayan. Ang mga hilera ay kilala bilang mga tuple at kumakatawan sa mga indibidwal na tala o mga pagkakataon, habang ang mga hanay ay mga katangian (o mga patlang) na tumutukoy sa mga katangiang nakaimbak para sa bawat tala.

Kunin nating muli ang dealership ng kotse bilang halimbawa . Maaari kang magkaroon ng talahanayan na "Salespeople" na may mga kolum tulad ng SalespersonID at Pangalan, at isang hiwalay na talahanayan na "Mga Kotse" na may mga kolum tulad ng CarID at Brand. Ang bawat hilera sa talahanayan ng Salespeople ay kumakatawan sa isang aktwal na salesperson, at ang bawat hilera sa talahanayan ng Mga Kotse ay kumakatawan sa isang aktwal na sasakyan.

Ang mga primary key at foreign key ay may mahalagang papel sa relational model . Ang isang primary key ay natatanging tumutukoy sa bawat row sa isang table (hal., SalespersonID o CarID). Ang mga key na ito ay maaaring lumitaw bilang mga foreign key sa ibang mga table upang kumatawan sa mga relasyon. Halimbawa, ang isang table na "Showrooms" ay maaaring magsama ng parehong SalespersonID at CarID bilang mga foreign key, na nag-uugnay sa isang showroom sa salesperson na nagtatrabaho doon at sa kotseng ipinapakita.

Ang kooperasyon sa pagitan ng mga primary at foreign key ang nagpapahintulot sa mga relational database na kumatawan sa mga kumplikadong web ng mga ugnayan sa negosyo . Kapag nag-query ka sa database, maaari mong pagdugtungin ang mga talahanayan sa mga key na ito, para sa pagsusuri ng data gamit ang SQL at upang muling buuin ang mga totoong kaugnayan sa mundo: kung aling mga kotse ang nakatalaga sa aling showroom, kung aling salesperson ang humawak ng isang partikular na benta, at iba pa.

Ang kooperasyon sa pagitan ng mga primary at foreign key ang siyang nagbibigay-daan sa mga relational database na kumatawan sa mga kumplikadong web ng mga ugnayan sa negosyo . Kapag nag-query ka sa database, maaari mong pagdugtungin ang mga talahanayan sa mga key na ito upang muling buuin ang mga totoong kaugnayan sa mundo: kung aling mga kotse ang nakatalaga sa aling showroom, kung aling salesperson ang humawak ng isang partikular na benta, at iba pa.

Ang modelong relasyonal ay makapangyarihan, lubos na nauunawaan, at lubos na sinusuportahan ng mga makabagong teknolohiya . Nagniningning ito kapag ang datos ay lubos na nakabalangkas at mahalaga ang pagkakapare-pareho. Gayunpaman, maaari itong makaranas ng mga limitasyon sa mga napakakumplikadong bagay, nilalamang multimedia, o mga ultra-flexible na iskema kung saan madalas na nagbabago ang istraktura.

Pagmomodelo ng datos na nakatuon sa object

Ang object-oriented data modeling ay nagdadala ng mga konsepto mula sa object-oriented programming sa mundo ng data . Sa halip na mag-isip lamang sa mga tuntunin ng mga talahanayan at hilera, minomodelo mo ang impormasyon bilang mga bagay na nagbubuklod ng data (mga katangian) kasama ng pag-uugali (mga pamamaraan), na sumasalamin sa kung paano isinusulat ang mga modernong aplikasyon.

Sa isang object-oriented model, ang bawat object ay kumakatawan sa isang totoong entity . Para sa isang car dealership, maaari kang magkaroon ng isang object na "Customer" na may mga attribute tulad ng pangalan, address at numero ng telepono, at mga method para i-update ang mga detalyeng iyon o kalkulahin ang customer lifetime value. Ang bawat aktwal na customer ay isang instance ng Customer class sa system.

Kayang malampasan ng ganitong istilo ng pagmomodelo ang ilang limitasyon ng mga mahigpit na relational na disenyo , lalo na kapag nakikitungo sa mga kumplikado at naka-nest na istruktura o multimedia data na hindi akma nang maayos sa mga flat table. Sinasamantala ng mga object database at object-relational mapper (ORM) ang paradigma na ito upang mabawasan ang "impedance mismatch" sa pagitan ng code at data storage.

Karaniwan ang mga object-oriented na modelo sa mga multimedia at advanced na sitwasyon ng aplikasyon , kung saan ang pag-iimbak ng mga imahe, video, o nested na dokumento bilang mga cohesive object ay mas natural kaysa sa paghahati ng lahat sa maraming relational table. Gayunpaman, maaari silang magdulot ng komplikasyon sa pag-query, pag-uulat, at integrasyon kung hindi ka mag-iingat.

Dahil ang object model ay kadalasang halos kapareho ng kung paano nag-iisip ang mga developer , mapapabilis nito ang pagbuo ng application. Ang kapalit nito ay ang mga purong object database ay hindi gaanong mainstream kaysa sa mga relational, at ang pagsasama ng mga ito sa mas malawak na data ecosystem (lalo na para sa BI) ay maaaring maging mas mahirap.

Pagmomodelo ng dimensional na datos para sa analytics at BI

Ang dimensional data modeling ang pangunahing pamamaraan para sa mga data warehouse at mga solusyon sa Business Intelligence . Ang pangunahing layunin nito ay i-optimize ang mga istruktura ng datos para sa mabilis na pag-query, pagsasama-sama, at pag-uulat, kahit na nangangahulugan ito ng sinasadyang pagdoble o pag-denormalize ng datos.

Sa isang dimensional na modelo, ang datos ay nakaayos sa mga fact table at dimension table . Ang mga fact table ay nag-iimbak ng mga quantitative at measurable na kaganapan (mga benta, pag-click, pagpapadala, transaksyon), habang ang mga dimension table ay nagbibigay ng mga descriptive na konteksto (oras, produkto, customer, lokasyon) na nagbibigay-daan sa iyong hatiin at suriin ang mga katotohanan sa maraming anggulo.

Isipin muli ang isang dealership ng kotse na nagtatayo ng isang data warehouse . Maaaring iimbak ng isang fact table ang bawat transaksyon sa benta, kabilang ang mga sukatan tulad ng dami at kita, habang ang mga talahanayan ng dimensyon ay maaaring maglarawan ng "Kotse", "Showroom" at "Oras". Ang dimensyong "Kotse" ay magsasama ng mga katangian tulad ng modelo at tatak; ang dimensyong "Showroom" ay magtataglay ng mga hierarchy tulad ng estado, lungsod, kalye at pangalan ng showroom.

Kadalasang sadyang kinokopya ng mga dimensional model ang ilang data sa mga talahanayan . Ang redundancy na ito ay isang sinasadyang pagpipilian sa disenyo upang mapabilis ang mga query at gawing madali ang pagsusuri para sa mga gumagamit ng BI. Maaaring i-filter, pagsama-samahin, at i-pivot ng mga analyst ang mga dimensional attribute nang hindi binabayaran ang parusa sa pagganap ng mga highly normalized relational schemas.

Dalawang klasikong pisikal na padron para sa mga dimensional na modelo ay ang star schema at ang snowflake schema , na parehong malawakang ginagamit sa mga proyektong BI. Pareho silang may analytical core ngunit magkaiba sa kung gaano na-normalize ang mga dimensyon.

Mga modelo ng datos sa Business Intelligence: bituin at niyebe

Sa mundo ng BI, kapag pinag-uusapan ng mga tao ang tungkol sa "modelo ng datos," madalas nilang tinutukoy ang star o snowflake schema sa likod ng kanilang mga ulat . Tinutukoy ng mga schema na ito kung paano nauugnay ang mga katotohanan at dimensyon, at malakas ang mga ito sa pagganap, usability, at flexibility ng mga analytics tool.

Ang star schema ay umiikot sa isang sentral na fact table na naglalaman ng mga panukat na sinusuri sa pinakamababang kapaki-pakinabang na antas ng detalye (ang grain), kasama ang mga foreign key na nag-uugnay sa mga nakapalibot na dimension table. Lahat ng dimensyon ay direktang nakakonekta sa fact table, na bumubuo ng hugis na parang bituin.

Malaki ang bentahe ng disenyong ito: pinapasimple nito ang pag-filter at mga pagsasama-sama . Dahil ang bawat dimensyon ay direktang nakakonekta sa fact table, ang mga query ay simple at mas madaling makakabuo ng SQL ang mga tool. Halimbawa, maaari kang magkaroon ng Sales fact table na direktang naka-link sa mga dimensyon ng Car, Customer, Showroom at Time, na lahat ay kumakalat na parang mga star point.

Kapag natukoy mo na ang mga dimensyong nauugnay sa katotohanang gusto mong suriin , maaari ka nang bumuo ng isang dimensional na modelo na sumasagot sa mga totoong tanong sa negosyo: Ano ang mga benta ayon sa tatak at rehiyon ng kotse? Paano umuusad ang mga resulta sa paglipas ng panahon? Aling mga showroom ang mas mahusay kaysa sa iba kung isasaalang-alang ang katulad na imbentaryo?

Gumagamit ang snowflake schema ng parehong konseptwal na mga bloke ng pagbuo ngunit ninonormalisa ang mga dimensyon sa maraming magkakaugnay na talahanayan . Sa halip na iisang dimensyon na "Lokasyon" sa bawat antas ng heograpiya, maaari mo itong hatiin sa "Bansa", "Rehiyon", "Lungsod" at iba pa, bawat isa ay nakaimbak sa sarili nitong talahanayan at naka-link sa isang normalized na istraktura.

Ang mga modelo ng Snowflake ay mas kumplikado kaysa sa mga star schema ngunit sinusunod ang parehong analytical logic. Ginagamit ang mga ito kapag ang data ng dimensyon ay malaki, ibinabahagi, o nangangailangan ng mas malakas na normalisasyon upang maiwasan ang redundancy. Halimbawa, ang isang dimensyong "Produkto" ay maaaring hatiin sa magkakahiwalay na mga talahanayan para sa "Produkto", "Tatak" at "Kategorya", na ang bawat isa ay ni-normalize at ikinokonekta sa pamamagitan ng mga key.

Madalas na pinaghahambing ng mga practitioner ang mga star at snowflake schema ayon sa mga pamantayan tulad ng performance, storage, maintenance effort at kadalian ng paggamit . Karaniwang nananalo ang mga star schema sa pagiging simple at bilis ng query, habang ang mga snowflake ay nakakatipid ng storage at nakakabawas ng maintenance kung saan ang mga dimension hierarchy ay kumplikado o madalas na ginagamit muli sa maraming fact table.

Mga modelo ng datos na patag, semi-istruktura at kaugnay

Bukod sa mga klasikong hierarchical, network, ER, relational, object at dimensional na mga modelo , may ilan pang ibang istilo na mahalagang malaman, lalo na sa mga modernong data platform at mga senaryo ng integrasyon.

Ang isang flat data model ang pinakasimpleng posibleng representasyon . Ang lahat ng data ay nakaimbak sa isang talahanayan na may mga hilera at haligi, nang walang anumang tahasang relasyon o istruktura na lampas doon. Upang ma-access ang isang partikular na subset ng impormasyon, maaaring kailanganin ng sistema na basahin ang maraming bahagi ng talahanayan, na nagpapabagal at nagpapahina sa mga operasyon habang lumalaki ang dami ng data.

Ang semi-structured model ay isang mas nababaluktot na ebolusyon ng relational approach . Sa semi-structured data, hindi ka laging may malinaw na paghihiwalay sa pagitan ng data at schema. Ang ilang entity ay maaaring may ilang partikular na attribute, habang ang iba ay maaaring may karagdagang field na wala sa kanilang mga kapantay, at iyon ay ganap na katanggap-tanggap.

Karaniwan ang kakayahang umangkop na ito sa mga format tulad ng JSON, XML o ilang NoSQL database . Ang isang katangian ay maaaring maglaman ng isang simpleng atomic value o isang buong koleksyon, at ang istraktura ay maaaring mag-iba sa bawat record. Ito ay mabisa kapag nakikitungo sa nagbabago o magkakaibang mga mapagkukunan ng data, ngunit pinapakomplikado nito ang mahigpit na pagpapatunay at tradisyonal na mga relational query.

Ang modelo ng associative data ay kumukuha ng isa pang pananaw sa pamamagitan ng paghahati ng data sa "mga item" at "mga link" . Anumang bagay na maaaring umiral nang nakapag-iisa ay itinuturing na isang item (o elemento), habang ang mga ugnayan sa pagitan ng mga item ay iniimbak bilang mga link (o mga asosasyon). Ang bawat elemento ay may pangalan at isang identifier, habang ang bawat link ay may sariling identifier at mga katangian na nakaturo sa isang pinagmulan, isang pandiwa at isang target.

Isaalang-alang ang pangungusap na "Ang World Cup ay gaganapin sa London simula Mayo 30, 2022" . Ang isang associative model ay maaaring mag-imbak ng isang link na nagsasabing "World Cup – ay ginaganap sa – London", kung saan ang "World Cup" ang pinagmulan, ang "ay ginaganap sa" ang pandiwa, at ang "London" ang target. Ang isa pang link ay mag-uugnay sa unang link na iyon bilang pinagmulan sa petsa ng pagsisimula bilang target, sa pamamagitan ng pandiwang "mula sa".

Ang perspektibong nakabatay sa link na ito ay maaaring maging lubhang nagpapahayag para sa mga knowledge graph at semantic relationships . Sa halip na itago ang mga relasyon sa loob ng mga table join o object reference, tinatrato mo ang mga ito bilang mga primera klaseng elemento ng data na maaaring i-query, i-version, at suriin sa sarili nitong paraan.

Konseptwal na pagmomodelo ng datos para sa pagsusuri ng negosyo

Ang konseptwal na pagmomodelo ng datos ay nakatuon sa pagkuha ng mga konsepto ng negosyo at ng kanilang mga ugnayan sa napakataas na antas , nang hindi nababahala tungkol sa mga teknikal na detalye tulad ng mga uri ng datos, mga indeks o pisikal na imbakan. Ito ay lalong kapaki-pakinabang sa mga unang yugto ng proyekto kapag pinapatunayan mo pa ang saklaw at mga kinakailangan.

Sa mga kapaligirang tulad ng Pega at mga katulad na platform, ang isang konseptwal na modelo ng datos ay nagsisimula sa pagtukoy ng mga entidad ng negosyo at ng kanilang mga katangian . Halimbawa, sa isang senaryo ng bodega ng libro, maaari mong tukuyin ang isang entidad na "Bodega" na may mga katangian tulad ng Pangalan, Lungsod at Kapasidad. Ang mga karagdagang entidad tulad ng "Address" at "Imbentaryo" ay iuugnay sa "Bodega" upang kumatawan kung saan matatagpuan ang pasilidad at kung anong mga libro ang hawak nito.

Ang resultang diagram ay nagpapakita ng mga entidad na iyon, ang kanilang mga pangunahing katangian, at ang mga pangunahing ugnayan sa pagitan ng mga ito . Hindi mo kailangang imodelo ang bawat punto ng datos na kinakailangan upang makamit ang resulta ng negosyo; ang layunin ay makuha ang pangkalahatang larawan upang makita ng mga stakeholder kung may anumang halatang nawawala o maling naipapakita.

Kapag nakikipagkita ka sa mga stakeholder ng negosyo, ang konseptwal na modelo ay nagiging isang ibinahaging sanggunian . Nakakatulong ito sa mga tao na mailarawan kung paano tumutugma ang kanilang mga proseso sa datos: kung aling mga entity ang kasangkot sa bawat hakbang, kung aling mga katangian ang kinakailangan upang makumpleto ang isang kaso, at kung saan umiiral ang mga dependency sa pagitan ng mga departamento o sistema.

Ang paglalaan ng sapat na oras sa konseptwal na disenyo ng datos nang maaga ay lubos na nakakabawas sa panganib ng muling paggawa sa ibang pagkakataon . Kung matuklasan mo sa kalagitnaan ng proyekto na ang mga kritikal na kinakailangan sa datos ay hindi naunawaan o hindi napapansin, maaaring kailanganin mong gawing muli ang mahahalagang bahagi ng disenyo ng proseso, mga integrasyon, at UI. Ang isang matatag na konseptwal na modelo ay nakakabawas sa panganib na iyon sa pamamagitan ng paglalantad ng mga hindi pagkakaunawaan habang mura pa rin ang pagbabago.

Siyempre, ang mga konseptwal na modelo ay hindi estatiko . Habang umuusad ang proyekto at mas natututo ang pangkat, ang modelo ay maaaring (at dapat) umunlad. Ang ebolusyong iyon ay isang tanda ng malusog na pagtuklas, hindi isang pagkabigo. Ang susi ay panatilihin ang konseptwal na modelo bilang isang buhay na dokumento na nagpapanatili sa mga talakayan ng proyekto na nakabatay sa isang malinaw na pananaw sa datos ng negosyo.

Mga modelo ng datos bilang buhay, estratehikong mga asset

Sa lahat ng mga pamamaraan at uri ng modelong ito, lumilitaw ang isang karaniwang tema: ang mga modelo ng datos ay hindi lamang mga teknikal na artifact; ang mga ito ay mga madiskarteng kagamitan sa komunikasyon . Gumagawa ka man ng isang simpleng ER diagram o nagpapanatili ng isang mayamang dimensional na schema para sa BI, kino-code mo kung paano nauunawaan ng organisasyon ang sarili nito sa anyong datos.

Sinusuportahan ng mahusay na pagkakagawa ng mga modelo ng datos ang mga pangunahing proseso ng negosyo, ginagabayan ang arkitektura ng IT at nagbibigay-daan sa maaasahang analytics . Nagbibigay ang mga ito ng ibinahaging bokabularyo sa pagitan ng mga pangkat ng negosyo at teknolohiya, binabawasan ang kalabuan, at ginagawang mas hindi gaanong masakit ang mga pagbabago sa hinaharap dahil ang epekto ng mga pagbabagong iyon ay maaaring masubaybayan sa pamamagitan ng malinaw na tinukoy na mga entidad at ugnayan.

Mula sa mga hierarchical tree at network graph hanggang sa mga relational table, object hierarchy, dimensional star, flat structure, semi-structured format at associative link , ang bawat istilo ng pagmomodelo ay may kanya-kanyang kalakasan para sa mga partikular na gamit. Bihirang gumamit ng isa lang ang mga modernong organisasyon; sa halip, pinagsasama nila ang maraming pamamaraan sa kanilang mga sistema at data platform.

Sa huli, ang halaga ng pagmomodelo ng datos ay nakasalalay sa kung gaano kabisa nitong ginagawang magkakaugnay at madaling i-navigate ang mga makalat na kinakailangan sa totoong mundo . Kapag ginawa nang may kahusayan ngunit kasama rin ang pragmatismo sa negosyo, ang mga modelo ng datos ay nagiging mga pangunahing asset na nagpapabilis sa pag-unlad, nagpapabuti sa kalidad ng datos at nagbibigay-kapangyarihan sa paggawa ng desisyon sa buong negosyo.