Intrarea romanilor in UE- studii de risc seismic (partea I)

    Nu va speriati, titlul nu se refera la niste consideratii legate de vreun cutremur provocat de intrarea
Romaniei in UE insa ce se poate spune este ca odata cu tara au intrat in UE si cladirile cu risc seismic ramase
prin cetatea lui Bucur, plasate in diverse sectoare ale capitalei.
    Mi-a atras atentia un coleg al meu preocupat de businessul asigurarilor dar si de sperietura unui iminent
si atat de “asteptat” cutremur de pamant; acesta a facut rost de lista de imobile, publica de altfel, care grupeaza
cladirile in 4 grupe: de la III (3) , in care respiri mai cu usurare pana la I+ (1+) unde nu numai ca respiri greu
dar e bine sa ai niste lumanari pe aproape in caz ca …
    Bun, gata cu sperietura, mi-am propus sa studiez in acest articol legaturile dintre date prin tehnicile de
data mining (minerit de date cum ne mai place sa le zicem) si, de ce nu , sa fac niste interpretari asa cum
o sugereaza datele. As vrea sa precizez (asa cum voi face la sfarsit), ca aceste consideratii sunt niste opinii personale
care nu implica in nici un fel institutii, sisteme sau  persoane etc. Revenind, intr-un articol viitor voi studia aceeasi
problema prin tehnicile data mining de pe langa Office 2007 precum si posibile noi interpretari ale datelor.

I.                    Configurarea studiului

Iata cum arata in niste selectiuni datele brute aflate in 4 documente pdf:

 

            Asa cum observati, datele din cele 4 tabele trebuie adunate si prelucrate asa cum scrie la carte pentru a fi o

sursa de date coerente si sigure. Aduse in Excel am facute mai multe prelucrari:

·          Am adaugat o coloana care detine gradul de risc;

·          Am pastrat un singur an de construire in cateva situatii (probabil acel imobil a fost refacut in trecut) – asta nu

afecteaza coerenta studiului nostru;

·          Am adaugat campul “Expert” care desemneaza institutia sau persoana care a expertizat imobilul; pentru imobilele

de grad mai scazut de risc am considerat ca expertul a fost Primaria (Capitalei);

·          Campul “ArieDesfasurata” are valoarea 0 pentru imobilele in care nu s-a precizat asta;

·          Campul RegimInaltime a ramas pe loc (apropos S+P+5E+Ma inseamna Subsol+Parter+5 Etaje+ Mansarda);

·          A trebuit sa folosesc niste functii Excel ca sa omogenizez datele, de exemplu , imobilele cu gradul 1 aveau combinat

tipul de artera cu denumirea arterei  ( ex. Strada Academiei) si a trebuit sa duc datele in campurile corespunzatoare.

Sursa de date apare in figura urmatoare :

      Mai departe duc datele in SQL 2005 intr-o baza de date special facuta prin mecanismul Import/Export al SSIS si aleg tipurile de date ale tabelei gazda asa cum apare in figura urmatoare :

            In continuare deschid un proiect in SQL Server Business Intelligence Development Studio . Configurez sursa de date si view-ul atasat dupa care trec , in ordine la modelele bazate pe algoritmii corespunzatori (care sunt vizibili in figura de mai jos)

  

    Trebuie precizat ca IdConstr este ales drept cheia iar Risc este coloana de predictie; An Constr si An Expertiza
au fost declarate “Discretized” astfel ca sistemul sa formeze plaje de ani in care vor incadra constructiile respective.
Apoi trec la procesarea datelor si sa vedem rezultatele

II Interpretarea datelor

    Interpretarea datelor o facem in mai multe parti , depinde de modul in care epuizam subiectul dar si de eventuale ajustari ale
proiectului.
    Aspectul “Dependecy Network” este vizibil , asa cum se stie la mai multi algoritmi si, pentru o prima evaluaream grupat asa:

 

    Legatura mai stransa intre Risc si celelalte atribute incepe de la “tare” la “slab” astfel :

·          Expert, An Constr, An expertiza, Regim Inalt in cazul Decision Trees;

·          Expert, regimInalt, An Expertiza, An Constr, Sector, Tip Artera in cazul Naïve Bayes

    Ce se vede cu ochiul liber este ca atributul Expert este identificat ca cel mai puternic pentru ambii algoritmi,
apoi anii de constructie si de expertiza. Daca dinspre anul de constructie era de asteptat sa primim acest rezultat tot
ce tine de aspectele de expertiza influenteaza atributul de risc. Sa fie oare momentul si calitatea expertizei direct
legata de aprecierea de risc ? Ramane sa atacam aceasta problema in articolele viitoare; oricum aspectul
Dependency Network al algoritmului Microsoft Association Rules nu afost tratat aici datorita complexitatii sale insa
va asigur ca da rezultate bune.

 
Gigi Ciubuc

 
Nota. Acest articol reprezinta opinii personale ale autorului, si trebuie tratat ca atare si nu are alte implicatii.

 

                                   

 

 

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Foarte interesant! Datele sunt publice?

As incerca cateva lucruri:

- separarea coloanei Regim Inaltime in 2 sau 3 coloane

•    - subsol (boolean)
•   - mansarda (boolean)
•   - numar etaje (int)
  Presupun ca toate cladirile au P(arter). O corelatie ar putea apare intre numarul de etaje si risc, corelatie ascunsa de eticheta acum

- E posibil ca expertul sa fie corelat puternic cu sectorul. E posibil ca acelasi expert sa analizeze mai multe cladiri dintr-un sector, caz in care expertiza nu mai influenteaza puternic riscul. Zona devine un factor mai important (probabil pentru ca zona + anul constructiei definesc in general in mare masura tipul constructiei). Faptul ca Sector apare in Naive Bayes (care-l trateaza ca variabila independenta) dar nu in Decision Trees (care are o maniera greedy de selectare a predictorilor), ma face sa cred ca Sector a puterninc corelat cu alta variabila. In plus, asta ar anonimiza rezultatele analizei (si reduce riscul de litigatie )

Ca sa raman in zona "safe", atasez si eu nota ta finala: "Acest mesaj reprezinta opinii personale ale autorului, si trebuie tratat ca atare si nu are alte implicatii."

---

b o g d a n c r i v a t
[sql server|data mining]

O sa incerc sa rafinez mai incolo proiectul cu ideile tale , insa o sa urmeze un set de articole-comentarii vis-a-vis de aceste rezultate.

sau chiar o sa tin cont de ele cand voi face o abordare prin Office 2007.

Subiectul dar si notitele de subsol nu fac decat sa dea niste friguri cand te gandesti ce se poate intampla ...

Ca sa anticipez un pic , Naive Bayes a descoperit ca Lipscanii si Calea Grivitei sunt cele mai periculoase zone !.

Rog cititorii sa nu ma transforme intr-un Hancu sau cum il chema pe celebrul prezicator de cutremure de pe la televiziuni de acu' cativa ani!

Se pare ca colegul meu a obtinut datele publicate pe site-ul www.capital.ro si cum nu-l stiu eu drept "hacker" cred ca le avea de undeva de unde

se putea servi toata lumea. Asa ca n-am ce face si reatasez notitza :

"Aceste lucruri reprezinta opinii personale ale autorului, si trebuie tratate ca atare si fara alte implicatii."

 

 

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Ca veni vorba de variabile corelate: in cartulia "DISCOVERING KNOWLEDGE IN DATA An Introduction to Data Mining" a lui Daniel Larose scrie asa:

"One should take care to avoid feeding correlated variables to one’s data mining and

statistical models. At best, using correlated variables will overemphasize one data

component; at worst, using correlated variables will cause the model to become

unstable and deliver unreliable results."

 

Din experienta voastra practica, e adevarat?

 Lucian

Cred ca depinde de algoritmul folosit. Pentru Naive Bayes, de exemplu, e perfect adevarat. De altfel, de aici vine parca si "Naive" -- de la presupunerea ca variabilele sunt independente. Arborii de decizie, pe de alta parte, nu cred ca sunt asa de sensibili la variabile corelate. Dupa primul split, dupa unul din predictori, in fiecare din noduri, variabilele corelate isi pierd importanta si al doilea split nu le va lua in considerare.

Acum, cand folosesti un algoritm care nu e atat de intuitiv ca arborii de decizie sau Naive Bayes, probabil ca cel mai bun lucru e sa elimini unele variabilele puternic corelate cu cele pe care le pastrezi. Aici, o solutie solida, dar mai putin intuitiva ar fi Principal Component Analysis, care iti transforma spatiul de variabile intr-un sub-spatiu cu mai putine dimensiuni, (aproape) independent. Variabilele generate de PCA nu sunt foarte intuitive (reprezinta proiectii ale mai multor variabile din setul originar pe niste axe).

O solutie simpla, rapida si intuitiva este Naive Bayes peste toate variabilele, marcandu-le pe toate atat Input cat si Predict (in terminologia SQL Server, asta ar fi "Predict", diferit de "Predict Only"). Dependency Net-ul construit pentru Naive Bayes arata foarte clar corelatii intre variabile.

Pe baza cunostintelor despre date se poate selecta un set aproape independent de variabile.

---

b o g d a n c r i v a t
[sql server|data mining]