Santrauka
Su daugeliu dalykų gyvenime susiduriama teisingai, tačiau yra dalykų, kuriuos verta turėti daugiau patirties, yra ir tokių, kurie kyla dėl padarytų klaidų, nes žinomas neigiamas gautas rezultatas, jo konteksto priežastys, dariusios įtaką klaidai ir klaidoms. stenkitės to nekartoti kuo daugiau.
Šis klaidų sąrašas statant įmonės duomenų saugyklą yra vienas iš pirmųjų straipsnių, kuriame siekiama sukaupti žinių bazę ir patirtį iš pamokų, įgytų vykdant informacinių technologijų projektus, šiuo konkrečiu atveju - įmonių duomenų bazių plėtros projektuose.
Šis sąrašas buvo sukurtas tam, kad būtų naudingas visiems žmonėms, kurie šiek tiek dalyvauja kuriant duomenų saugyklą, ir leis įvertinti, kuriuo keliu jie eina ir kokios yra galutinės sėkmės galimybės, tačiau labiausiai susintetinti patarimai, kurių galima pasisemti iš tai yra palaikyti bendrą darbą dalyvaujančiuose lygmenyse ir organizacinėse srityse, taip pat dirbti su tvirtu teoriniu-praktiniu susijusios technologijos pagrindu.
Šio sąrašo tikslas - suteikti informacijos apie įgytas žinias, pritaikytas šios technologijos taikymo srityje įvairiose įmonėse, ir pateikti teorinį-praktinį pagrindą, pagrįstą informatikos sritimi ir, teisingiau, „datawarehouse“ technologija, ir tai galiausiai turėtų lemti jūsų įmonės korporatyvinių duomenų saugyklos projekto sėkmę ateityje.
Raktažodžiai: „datawarehouse“, „datamart“, duomenų gavyba, įmonės duomenų saugyklos statyba, bendros klaidos, duomenų valdymo sistemos projekto valdymas, duomenų bazės pastatymo rizika, duomenų bazės perspektyvos, pelningumo metrika investuojant į duomenų saugyklą
Indeksas
1. Įvadas
2. 10 dažniausiai pasitaikančių klaidų, susijusių su įmonės duomenų programinės įrangos statyba, sąrašas
3. Išvados
4. Bibliografija
1. Įvadas
Šiandien daugumos finansų ir komercinių kompanijų, kurios dar visai neseniai daugiausiai pastangų skyrė transakcijų informacinėms sistemoms teikti, technologijos sritys, kurios palaikė daugumos jų vertės grandinių veiklos naštą. Jie orientuojasi į nuoseklų jų saugomų duomenų išnaudojimą: istorinė ir transakcinė, realybė aplink ją yra milžiniškas duomenų, gautų iš kasdienių jų transakcinių sistemų operacijų, dydis, ir analizės bei žinių iš viso to įgijimo problema. informacija, kuri lieka palaidota savyje.
Yra keletas skaičiavimo metodų, leidžiančių šią operatyvinę, operatyvinę ir kasdienę informaciją paversti informacija, kurios apibendrinimo, tikslios ir specializuotos temos yra skirtingo lygio, ir kuri leidžia jas analizuoti, palengvinant vadovų sprendimų priėmimą, Ši technologija vadinama „Data Repository“ arba „Datawarehouse“.
Remiantis profesine praktika, duomenų saugyklos statyba nėra apsaugota nuo problemų, kurios trukdo pasiekti sėkmę ir pasiekti galutinį tikslą: paramą vadovybės sprendimų priėmimui.
Straipsnyje bandoma peržengti teorinę problemą, pateikti problemines problemas, kurios trukdo sėkmingai plėtoti įmonės duomenų saugyklą.
Todėl reikėtų patikslinti, kad šis sąrašas - dažniausiai pasitaikančių klaidų plėtojant korporatyvinį duomenų saugyklą - susidaro plėtojant šią technologiją reprezentacinėse įmonėse, priklausančiose Peru finansų ir prekybos sektoriui.
Darant prielaidą, kad projektas turi tenkinti klientą reprezentuojant jų investicijų grąžą - mes žinome, kad tai ne visada lengva įvertinti kompiuterinių technologijų projektuose, tačiau duomenų saugyklos plėtros projekto sėkmė yra tiesiogiai proporcinga naudingumui, gautam analizuojant informacija priimant teisingus sprendimus, kuriuos naudinga įmonei, šiuo metu: daugiausia žinant, kad priimtas sprendimas, pagrįstas duomenų analize per duomenų saugyklą, sukuria didesnes pajamas ir (arba) santaupas Tinkamas įvertinimas, todėl turime atsižvelgti į ataskaitų gavimo paprastumą ir jos konfigūravimo lankstumą.Svarstoma, ar reikia mokytis iš kiekvieną kartą priimamų sprendimų, kaip svarbu kaupti suvestinių duomenų ir ataskaitų formą ir informaciją, laikui bėgant parodyti kaip jų vertę įmonei.
Šis sąrašas, tinkamai panaudotas, leis projekto valdytojams, savininkams ir klientams tiksliau priimti sprendimus, žinant galimas vienos ar kitos nustatytos strategijos ar priemonės pasekmes ir užkertant kelią dažnoms klaidoms, leidžiant sutaupyti išlaidų, formuojant, plėtojant ir įgyvendinant projektą.
2. 10 dažniausiai pasitaikančių klaidų, susijusių su įmonės duomenų programinės įrangos statyba, sąrašas
1-oji klaida: Tarkime, kad problemų, kurios gali kilti, sprendimas yra grynai techninis klausimas
Duomenų saugyklai reikalingas aktyvus vadovų sprendimų priėmėjų dalyvavimas.
2-oji klaida: nepaskiriant tinkamo viso projekto biudžeto.
Tinkamas kapitalo ir išteklių paskirstymas palaikant ir veikiant technologinei platformai ir infrastruktūrai, kurios reikalauja įmonės duomenų saugykla, turi būti vienas iš pradinių aspektų, svarstant tai kaip projektą.
3-oji klaida: trūksta vyresniosios vadovybės įsipareigojimų.
Norint, kad įmonės duomenų saugykla būtų sėkminga, reikalingas visiškas aukščiausios vadovybės palaikymas, pagrįstas projekto valdymui ir jo kūrimo komandai suteiktu saugumu ir pasitikėjimu, kad darbas vyktų sklandžiai visose organizacinėse srityse, susijusiose su projektu.
4-oji klaida: Neturite tinkamos infrastruktūros jai palaikyti.
Bendrovės duomenų saugyklai reikalinga tinkama technologinė ir organizacinė infrastruktūra. Duomenų saugyklos sistemos architektūra svyruoja nuo patentuotų duomenų bazių serverių, duomenų transformavimo ir valymo serverių, visą organizaciją surenkančių vartotojo valdymo mazgų. Programinė įranga reikalauja serverio, kliento ir verslo sluoksnių programų, kurios efektyviai veikia n-dimensijų užklausų aplinkose ir lygiagrečiai.
5-oji klaida: nereikalingos, neskaidrios ir dokumentų neturinčios duomenų bazės.
Sandorių duomenų bazių, iš kurių bus išgauta informacija, kuri bus transformuojama ir saugoma duomenų laikmenoje, būklė į pradinius laiko įverčius paprastai neatsižvelgiama, tačiau tai gali reikšti didelę vėlavimą, bet kuriuo atveju, idealu subjektų, tokių kaip sąskaitos, klientai, skolos, mokėjimai ir kt., būsenos saugomi istorinėse lentelėse reikšmingą laiko tarpą pagal vidutinį kintamumo dažnį (kas mėnesį, kas dvi savaites, kasdien) ir standartine forma, tačiau praktikoje ši informacija randama kaip valdymo ataskaitoms naudojamų lentelių dalis, kurios jau yra išfiltravusios procesą, todėl praranda istorinių duomenų ir jų būsenų pokyčių nuoseklumą laiko atžvilgiu Verslas.
Kai kuriais atvejais rekomenduojama atlikti nepriklausomą duomenų bazių pertvarkymą operacijų lygmeniu, kai subjektų būsenų pokyčiai gali būti saugomi švariai, kaip ankstesnį žingsnį apsvarsčius galimybę išgauti duomenis iš jų kilmės.
6-oji klaida: nesugebėjimas sukurti visapusiško DBA ir duomenų saugyklos komandos bendradarbiavimo aplinkos.
Pradėdami duomenų saugyklos projektą įmonėje, DBA duomenų bazių administratorių zona paprastai jau egzistuoja, todėl rekomenduojama sukurti „Datawarehouse“ sritį tame pačiame lygyje kaip ir DBA - o ne kontroliuojant DBA. Daugybė DBA yra atsakingos už duomenų bazių, palaikančių kasdienes operacijas, priežiūrą. Sukurti alternatyvią platformą, pakankamą duomenų saugyklos plėtrai, turėti prieigą prie duomenų saugyklos srities informacijos šaltinių tiesiogiai, o ne kaip tarpininkams prie DBA, yra vienas iš svarbių veiksnių, prisidedančių prie greitesnio projekto vystymosi, ir kad siekti sėkmės.
7-oji klaida: nenaudojama valdymui tinkama reikalavimų specifikacijos metodika.
Viena iš dažnai pasitaikančių klaidų, kai reikalaujama, kad valdymo vartotojai nurodytų specifikacijas, nenaudoja metodikos, leidžiančios vartotojui lengvai išreikšti savo reikalavimus ir pasiruošusiems vėlesniam atsiliepimui.
Rekomenduojama naudoti prototipus, taip pat paruošti funkcinius specifikacijos dokumentus, susijusius su valdymo sritimis.
8-oji klaida: vertės grandinės nežinojimas, informacijos srautai verslo veikloje.
Identifikuoti veiklą, kuri yra kritiniai sėkmės veiksniai, taip pat stebėti centrinės kompetencijos veiklų srautą, kuris leidžia pasiūlytiems produktams ar paslaugoms suteikti vertę klientui, yra verslo žinių užduotis, kurios duomenų saugyklos dizaineriai neturi perduoti. apeinant tai pasirenkant projekto plėtros strategiją, pagrįstą bendru duomenų apdorojimo pagal procesus ar organizacines sritis modeliu, kuris leidžia nustatyti prioritetus pagal įmonės strateginį planą.
9-oji klaida: neturi integracijos perspektyvos su kitomis susijusiomis technologijomis.
Tvirta informacinių technologijų teorinė bazė ir platus esamų tendencijų bei sprendimų spektras leis sukurti duomenų saugyklą su ateities vizija. Šiuo požiūriu susijusios technologijos yra: OLAP, leidžianti analizuoti istorinę informaciją, siekiant nustatyti elgesio modelius, kita vertus, duomenų gavyba, leidžianti aptikti elgesio modelius, tačiau automatiškai naudojant modelius ir algoritmus (sprendimas medžiai, sankaupos, tinklo neuronai, miglota logika, tiesinė regresija ir kt.), Šiek tiek toliau yra įmonės subalansuotos rezultatų kortelės įdiegimas, kur duomenų saugykla teikia informaciją iš rodiklių už istorinius laikotarpius.
10-oji klaida: netinkamas projekto valdymas ir projekto plėtros plano nutraukimas.
Projekto vadovo gebėjimai išryškėja visu realiu aspektu - tiek techniniu, tiek žmonių mokymu, tiek panašių projektų patirtimi. Duomenų saugyklos plėtra turi būti cikliška ir etapais vykdoma analizės, projektavimo, kūrimo, bandymo veikla; pasikartojantys etapai, bandant išvengti pasikartojančių darbų.
3. Išvados
Šis straipsnis yra straipsnių, kuriuos autorius pateikia apie informacines technologijas, serijoje, ypač šiame straipsnyje, sąrašas, kuriame pateikiamas 10 dažniausiai pasitaikančių klaidų, vykstančių plėtojant įmonių duomenų saugyklos statybos projektus, sąrašas..
Teorinis pagrindas, kuriuo grindžiami šios klasės projektai, prasideda nuo daugiamatės informacijos duomenų bazių (ontologija, koncepcinių duomenų modelis, semantinis aiškinimas, rinkinių ir santykių teorija) koncepcijos, iš kurių tikimasi gauti tikslią informaciją., tiksli ir apibendrinta, kad būtų galima analizuoti ir palaikyti vadovo sprendimus.
Praktinis pagrindas buvo gautas autoriui dalyvaujant įvairiuose duomenų bazių projektuose svarbiose Peru komercinėse ir finansinėse įmonėse, kurių patirtis yra impregnuota šiame straipsnyje, ir pateikiama skaitytojui kaip konsultavimo įrankis ir teorinis-praktinis pagrindas., siekiant sėkmės ateityje kuriant įmonės duomenų saugyklą.
4. Bibliografija
1. Duomenų saugyklos sukūrimas Autorius WH Inmon Editorial John
„Wiley & Sons, Inc.“ Niujorkas, Niujorkas, JAV, 1996 m
2. Duomenų saugyklos gyvavimo ciklo priemonių rinkinys: ekspertiniai duomenų saugyklų projektavimo, kūrimo ir diegimo metodai. Autoriai Ralph Kimball, Laura Reeves, Warren Thornthwaite, Margy Ross, Warren Thornwaite Redaktorius John Wiley & Sons, Inc. Niujorkas, NY, JAV 1998 m.
3. Realizuotas duomenų atrankos genetinis algoritmas
Sandėlių aplinka „Springer Berlin“ / Heidelbergo redakcija
1999 metai
4. Duomenų saugyklų modeliavimas ir kokybės klausimai Autorius: Panos Vassiliadis - Žinių ir duomenų bazių sistemų laboratorijos informatikos skyrius - Elektros ir kompiuterinės inžinerijos katedra - Atėnų nacionalinis technikos universitetas - Zographou 157 73, Atėnai, GRAIKIJA phd.pdf
5. Duomenų saugyklos rodinių priežiūra naudojant standartizaciją
Autoriai: Mukeshas Mohania, Kamalis Karlapalemas, Millistas Vincentas D.
Ram, redaktorius, Duomenų valdymas, 32–50 psl. „Springer Verlag“, 1997 m.
6. Duomenų saugyklų projektavimo metodika: koncepcinis modeliavimas Autoriai José María Cavero Universidad Rey Juan Carlos, Ispanija, Esperanza Marcos Universidad Rey Juan Carlos, Ispanija, Mario Piattini Castilla-La Mancha universitetas, Ispanija, Adolfo Sánchez Cronos Ibérica, SA, Ispanija. Leidėjas IRM Press Hershey, PA, JAV, 2002 m
7. Duomenų kokybės valdymo duomenų saugojimo sistemose strategija
1 / IQ01HelfertMaur.pdf
