Cartografierea este o tehnologie care poate fi folosită pentru a proiecta videoclipuri sau imagini diferite feluri suprafețe: clădiri, mașini și așa mai departe. Vă permite să organizați programe de spectacol distractive și fascinante, atât pe străzi, cât și în interior. Astfel de spectacole captează întotdeauna atenția publicului, lăsând o impresie uriașă. În acest caz, privitorul nu trebuie să poarte ochelari sau alte dispozitive.

Tehnologia vă permite, de asemenea, să faceți publicitate pentru orice pe suprafețe dure. Spectacolele create folosind această tehnologie se potrivesc perfect cu evenimente majore, sărbători în oraș, deschideri mari de magazine, centre comerciale și diverse facilități de divertisment. În același timp, cel mai mare efect poate fi obținut prin desfășurarea unui spectacol de cartografiere pe timp de noapte. Mai ales dacă este însoțit de artificii strălucitoare și muzică live.

Una dintre varietățile de cartografiere este cartografierea 3D. Datorită tehnologiei de cartografiere 3D, clădirile, mașinile și diferitele elemente interioare pot fi aduse la viață, oferind privitorului un sentiment al mobilității acestor obiecte. Legea de bază a tehnologiei de cartografiere 3d este destul de simplă: obiectele proiecției imaginii trebuie să corespundă cât mai aproape cu imaginea de proiecție. Puteți comanda un astfel de serviciu pe site-ul www.3dday.ru.

Cum functioneaza?

La proiectarea imaginilor asupra obiectelor din jur, trebuie să se țină cont de parametrii geometrici ai acestora din urmă. Tehnologia de cartografiere 3D presupune utilizarea unor echipamente specializate care proiectează imaginea în așa fel încât privitorul să o vadă ca tridimensională din orice unghi. În cazul mapării video, efect vizual imaginea volumetrică este vizibilă doar dintr-o anumită poziție. Aceasta este diferența dintre tehnologia de cartografiere convențională și tehnologia de cartografiere 3D.

Pentru a crea iluzie optica, în primul rând, reproduce imaginea obiectului proiectat pe un computer sub forma unui model 3d. În plus, acest model este ajustat în funcție de cerințele scenariului emisiunii. Etapa finală este proiectarea modelului creat pe un obiect real, conform căruia a fost proiectat modelul.

Astfel, tehnologia de cartografiere 3d, care este simplă la prima vedere, creează o iluzie optică puternică: privitorului i se pare că obiectul în sine se schimbă, când, de fapt, doar proiecția se schimbă. Impresia unei astfel de iluzii optice este cu adevărat incomparabilă. Și este ușor de imaginat efectul posibil al campanie publicitara, realizat cu ajutorul cartografierii!

Alte articole ale autorului:

În acest articol, dorim să sistematizăm experiența noastră în efectuarea migrării datelor în proiecte corporative mari legate de tranziția Clienților la lucru în configurațiile 1C:Enterprise 8.

Totodată, accentul principal în articol va fi pus, în primul rând, pe componenta tehnologică a procesului de migrare. Este afectată și componenta organizatorică, dar într-o măsură mai mică.

Termeni și definiții

Migrarea datelor este de obicei înțeleasă ca o secvență finală de lucru, un proiect care vizează o mișcare unică în masă a datelor de la sistemele sursă (sisteme istorice) la un sistem receptor. În același timp, operarea acestor date în sistemele sursă este încheiată.

Migrarea datelor ar trebui să fie diferențiată de integrarea datelor. Integrarea, spre deosebire de migrare, este o parte permanentă a arhitecturii IT și este responsabilă pentru fluxul de date între ele diverse sistemeși depozite de date - și este un proces, nu o activitate de proiect.

Schema de migrare în general arată astfel:

Orez. unu

Sisteme istorice- bazele de date ale companiei Clientului, care sunt planificate a fi înlocuite total sau parțial în timpul implementării noului sistem.

Sistem receptor- sistem țintă, configurație arbitrară „1C:Enterprise 8”.

Datele inițiale- date descărcate din sistemele istorice într-un format arbitrar de fișier xls. LA acest caz formatul xls pare a fi unul dintre cele mai convenabile, deoarece capacitatea de a încărca într-un fișier xls este prezentă în multe sisteme de contabilitate din „generația anterioară”.

Cum alternativă modernă este posibil să se considere formatul fișierelor xml ca un transport.

Există, de asemenea, opțiuni pentru utilizarea unei baze de date intermediare.

Transformare, conversie- procesul de conversie a datelor brute în date pentru descărcare. Transformarea datelor are loc în conformitate cu șabloanele pentru încărcare. Rezultatul transformării sunt datele care trebuie încărcate.

Date de descărcat- datele care urmează să fie încărcate în sistemul receptor. În acest articol, precum și datele sursă, este luat în considerare formatul xls.

Descărcați șabloane de date- descrierea tabelelor de date în care trebuie încărcate sistem țintă.

Etapele migrației

Luați în considerare procesul de pregătire și desfășurare a migrației pas cu pas.

Etapele organizatorice ale migrației includ următoarele elemente:

· Definiți strategia de migrare. Pe această etapă Antreprenorul și Clientul sunt de acord cu privire la tehnologia muncii de migrare;

· Determinarea componenței grupului de lucru pe migrație. Grupul de lucru ar trebui să includă specialiști atât din partea Antreprenorului, cât și a Clientului, care sunt suficient de familiarizați cu funcționarea sistemelor istorice (din partea Clientului) și cu sistemul țintă (din partea Antreprenorului);

· Plan preliminar de migrare. Planul de migrare va fi ajustat în mod repetat pe parcursul derulării proiectului;

· Perioade de date pentru descărcarea datelor din sistemele istorice, volume de date. Perioadele limită de date pentru migrare, datele de testare și migrarea finală. Aceste informații pot fi atribuite planului de migrare;

· Compoziția datelor de migrat. Date de referință, clasificatoare, date tranzacționale, solduri, cifre de afaceri etc.;

· Probleme de verificare a calității, corectitudinii și integrității datelor în timpul și după migrare;

· Probleme de rollback la starea anterioară în caz de defecțiuni.

Să ne oprim mai detaliat asupra etapelor tehnologice ale migrației.

Orez. 2

1.Pregătirea șabloanelor de încărcare a datelor

Șablonul de încărcare a datelor conține descrieri tehnice tabele de date de încărcat, algoritmi și reguli de încărcare pentru șablonul curent.

Fiecare șablon este, în general, destinat pentru unul sau mai multe tabele înrudite pe sistemul destinație țintă.

Șablonul specifică:

Descrierea tuturor câmpurilor fișierului de date xls care urmează să fie încărcat, inclusiv:

o Nume câmp

o Semn de câmp obligatoriu

o Exemplu de umplere a câmpului

o Notă

Descrierea regulilor de încărcare a tabelului sistemului țintă pe baza datelor de încărcat (ordine în cazul mai multor tabele înrudite, algoritmi de căutare pentru câmpurile cheie etc.)

· Descrierea completării directe a câmpurilor tabelelor sistemului țintă în cazul în care se are în vedere altceva decât transferul de date unu-la-unu din fișierul de date pentru încărcare. Relevant pentru câmpurile de referință, de exemplu.

În cursul lucrărilor din această etapă, Antreprenorul trebuie să pregătească și un încărcător de fișiere de date pentru încărcare. În cazul lucrului cu fișiere xls, această sarcină nu este deosebit de dificilă.

2. Identificarea surselor de date

Acest pas poate începe împreună cu pasul anterior „1. Pregătirea șabloanelor de încărcare a datelor”.

În cadrul acestei etape, specialiștii Clientului stabilesc din ce sisteme și ce date pot fi încărcate. De asemenea, este necesar să se determine ce date Poate poate fi nevoie.

De regulă, în proiecte mari migrarea, identificarea unei liste complete exhaustive de surse de date poate dura destul de perioadă lungă de timpși are loc pe măsură ce munca progresează în etapele ulterioare.

Nu sunt neobișnuite situațiile în care, pentru a asigura integritatea informațiilor în viitor, unele date trebuie să fie transferate din surse tipărite (digitizate) sau chiar introduse în tabele din cuvintele angajaților cheie ai Clientului.

Cu toate acestea, în această etapă, ar trebui să încercați să identificați cât mai multe dintre datele necesare.

3.Descărcarea datelor inițiale

Procesul de descărcare a datelor din sistemele istorice poate dura suficient timp, mai ales dacă există multe sisteme, acestea sunt diferite și diferite departamente ale Clientului sunt responsabile pentru acestea. Ar trebui luat în considerare acest momentîn timpul migrațiilor de testare și finale.

Cel mai opțiune convenabilă se pare că se încarcă în fișiere xls. Multe sisteme IT mai vechi acceptă această opțiune.

Pot exista și opțiuni de încărcare în format csv, dbf, xml și altele.

Trebuie menționat că dintr-un motiv sau altul (probleme de securitate, de exemplu) Clientul nu poate furniza întotdeauna datele încărcate în întregime în această etapă! Doar o structură de date și câteva poziții de testare. Astfel, poate apărea o situație în care în timpul testului și al încărcărilor finale, în tabelele sursă se vor găsi date de proastă calitate, ceea ce va duce la erori neplanificate.

Pentru a minimiza această problemă, volumele de descărcări de testare din sistemele istorice ar trebui specificate în avans.

4. Maparea datelor

Mapping (data mapping) - în cazul general, procesul de comparare a datelor din sistemele istorice și sistemul de recepție. Adică datele sursă și datele de încărcat.

Etapa de cartografiere este cea mai consumatoare de timp și poate ocupa mai mult de 50% din toată munca la sarcina de migrare.

În această etapă în in totalitate toate grup de lucru proiect de migrație.

În procesul de mapare a datelor, este necesar să se distingă sub-etapele mapării tabelelor și mapării câmpurilor.

· Cartografierea tabelelor sau maparea şabloanelor - compararea tabelelor de date iniţiale şi a şabloanelor de date pentru încărcare. Corespondența poate fi fie 1:1, fie N:N. Ca rezultat al acestei lucrări, este compilat și menținut un registru de mapare a tabelelor. Acest subpas este necesar pentru următorul subpas de cartografiere a câmpului și pentru a ține evidența progresului general de cartografiere.

· Maparea câmpurilor - compararea câmpurilor de tabele în cadrul cartografierii tabelelor deja definite. Rezultatul acestei lucrări este un registru de cartografiere a câmpului.

În această etapă, ar trebui, de asemenea lucrări posibile pentru normalizarea datelor.

5. Pregătirea regulilor de transformare

Spre deosebire de etapele anterioare, această etapă este tehnică și implică munca dezvoltatorului Antreprenorului.

Pe baza registrelor de cartografiere a terenului agreate, specialiștii Contractorului dezvoltă reguli de transformare a datelor.

Pentru munca operaționalăîn timpul etapelor pregătitoare de migrare și mai departe, în timpul migrațiilor de testare și finale, este important să existe un mediu convenabil pentru dezvoltarea regulilor (script-urilor) pentru transformarea datelor și un mediu pentru conversia datelor sursă în date pentru încărcare.

Cerințele pentru acest mediu includ:

· Comoditatea și viteza de dezvoltare a regulilor de transformare;

· Viteza de conversie a datelor. Fișierele de intrare și de ieșire pot avea sute de mii de linii!

· Abilitatea de a lucra cu mai multe fișiere de intrare simultan;

· Abilitatea de a salva regulile de transformare în fișiere separate.

Pentru proiectele noastre de migrare, am dezvoltat o stație de lucru specializată pentru dezvoltatori, bazată pe procesarea standard a „Consolei de solicitări” 1C.

Gestionarea „Consola de interogări” a fost îmbunătățită pentru a permite solicitări directe către fișierele xls.

Iată un exemplu de combinare a două fișiere xls sursă Angajații.xls

și Operațiuni.xls cu pagini:

Anulări de datorii

și Sursa de venit:

Rețineți că exemplul este artificial, special selectat pentru a demonstra toate etapele posibile ale transformării sursei de date.

Secvența tehnologică a operațiilor de transformare aici este următoarea:

Folosind limbajul de interogare Access SQL (care oferă un nivel semnificativ caracteristici suplimentare, în comparație cu limbajul de interogare 1C), este creată o interogare inițială care preia date din fișier xls miercuri 1C. În același timp, deja în această etapă este posibil diverse verificăriși normalizarea datelor.

Tehnologia de acces la date ADO oferă de mare viteză muncă.

Orez. 3

2. Solicitare în limbajul 1C - cererea principală care implementează algoritmul de mapare a câmpului. Și de asemenea: îmbogățirea datelor descărcate cu date din baza de date 1C, regrupare, fuzionare cu rezultatele interogărilor la alte fișiere xls sursă etc.

3. Post-procesare a rezultatului cererii 1C, dacă este necesar. Este implementat folosind un script în limbajul 1C.

De exemplu, adăugarea liniei „TOTAL” pentru coloanele de sume este implementată aici.

4.Înregistrarea setului de date final în fișierul xls.

În cazul general, la ieșire obținem fișierele finale pentru încărcare în baza de date țintă 1C.

De asemenea acest instrument vă permite să salvați regulile de conversie a datelor într-un fișier xml separat:

În plus, se poate lucra în modul lot, ceea ce este valabil mai ales pentru în număr mare date de migrare eterogene.

În etapele anterioare, partea pregătitoare a lucrării în ansamblu se încheie - toate sursele de date sunt identificate, datele sursă sunt descărcate din surse, sunt pregătite șabloane pentru încărcare în baza de date țintă, este pregătită maparea datelor și, în final, datele sunt dezvoltate scripturi de transformare.

Trebuie remarcat faptul că înainte de migrarea finală, cu siguranță ar trebui să efectuați mai multe teste. În timpul migrărilor de testare, Antreprenorul împreună cu Clienții identifică:

erori de conversie, erori de încărcare a datelor

executa evaluarea preliminară calitatea datelor încărcate în sistemul țintă

Pe baza rezultatelor migrărilor de testare, aceștia întocmesc/actualizează planul final de migrare

7.Verificarea datelor

Verificarea calității datelor descărcate trebuie efectuată atât după migrarea testului, cât și la sfârșitul migrării finale. În timpul reconcilierii, pot fi verificați următorii indicatori:

· Coincidența totalurilor pentru solduri, pentru documente;

Potriviri cantitative, cum ar fi numărul de sisteme de operare;

· Corectitudinea umplerii entităților selective separate;

Vă rugăm să rețineți că anumite verificări ale datelor de migrare, problemele de normalizare a datelor trebuie abordate pe parcursul tuturor proceselor de migrare. Trebuie să vă întrebați întotdeauna ce trebuie făcut în etapa actuală pentru a evita greșelile în etapele ulterioare.

De exemplu:

· Verificați dacă există duplicate după câmpurile cheie. Este posibil și necesar să se efectueze încă pe datele inițiale;

· Tipuri de câmpuri de turnare;

· Integritate referenţială;

· Incoerențe matematice. De exemplu, verificarea câmpurilor numerice goale, care sunt planificate să fie împărțite în timpul transformării;

· În general, verificarea completării obligatorii a câmpurilor;

· Înlocuirea caracterelor incorecte. De exemplu, caractere englezești în câmpurile chirilice („o”, „a”, „e”, etc.) Acest lucru este valabil mai ales pentru câmpurile cheie!

Verificarea valorilor câmpurilor de șir pentru conformitate cu tipurile de sistem de recepție (Restricții de lungime)

După finalizarea migrării finale, în conformitate cu o strategie de migrare predeterminată și un plan de migrare, se ia o decizie privind funcționarea ulterioară a sistemelor moștenite.

Adesea, operațiunea se încheie imediat după reconcilierea finală a datelor și se înregistrează succesul migrării - utilizatorii noului sistem nu mai țin înregistrări în paralel în două sisteme, ci trec complet la sistem nou. În același timp, accesul la vechiul sistem este păstrat în modul citire.

În unele cazuri, operarea în paralel a două sisteme poate avea loc pentru perioada de funcționare de probă (OE) și chiar mai mult decât această perioadă. Întrebare munca paralela utilizatorii din două sisteme este strâns legată de problema posibilității de rollback la vechiul sistem, în cazul în care migrarea (sau, în general, funcționarea noului sistem!) se dovedește a fi nesatisfăcătoare.

Concluzie

În concluzie, aș dori să remarc că, atunci când vine vorba de migrarea sistemelor tranzacționale mari, care includ multe configurații 1C:Enterprise, trecerea la un sistem nou poate fi foarte consumatoare de timp.

Prin urmare, trebuie amintit că orice astfel de proiect necesită o pregătire atentă și trebuie să fie însoțit de un plan individual. Oricum, indiferent de tipul de sisteme migrate, de volumul bazelor de date etc. schema generala migrația arată aproape identică.

Problemă

Ați încărcat un raport de cheltuieli și doriți să îl afișați conducerii. Pentru a face acest lucru, trebuie să compune aceste articole contabilitate- conform articolelor de contabilitate de gestiune. Știți cum se leagă elementele BU și CS între ele, dar este nevoie de prea mult timp pentru a pregăti manual un astfel de raport de fiecare dată.

Soluţie

Vom lua în considerare acest caz ca o continuare a precedentului. Imaginați-vă că ați creat următoarea carte de referință în Excel:

Fig.2.1. Manual: cartografierea articolelor BU și CS

În stânga este un element de cost (BU), în dreapta este un articol contabil de gestiune (MC). În același timp, este important ca elementul de cost din prima coloană să apară o singură dată, altfel mecanismul de mapare nu va funcționa corect.

(Apropo, cuvântul englezesc mapping este tradus ca o mapare sau corespondență, deci directorul în acest caz este un fel de regula generala cum articolele BU își găsesc reflectarea în articolul CU).

Fig.2.2. Masa plat: raport de cheltuieli (din Contul 20 Cifra de afaceri)

Să fim atenți că în coloana a 7-a a apărut coloana „Articolul UU”. Vizavi de fiecare element de cost, punem un articol contabil de gestiune. Acest lucru se poate face manual, dar este mult mai convenabil să utilizați acest instrument:

Fig.2.3. Masa plat: raport de cheltuieli (din Contul 20 Cifra de afaceri)

Numele paginilor sunt indicate în partea de jos a formularului: „Principal” este un tabel plat care conține date de cost (Fig. 2.2), „ref” este o carte de referință (Fig. 2.1).

Numerele coloanelor sunt indicate în partea de sus a formularului. Deci, în acest caz, dacă datele din coloanele 1 ale directorului și 3 ale paginii principale sunt aceleași, atunci datele din coloana a 2-a a directorului sunt copiate în coloana a 7-a a paginii principale.

În această formă, există și multe opțiuni suplimentare. De exemplu, puteți activa casetele de selectare „Atribut #2” și „Atribut #3”, iar apoi transferul datelor din coloana 2 a căutării în coloana 7 a paginii principale va fi posibil dacă căutarea și Pagina principală budu potrivește imediat pentru două sau chiar trei detalii.

Ca urmare a unei operații atât de simple cu ajutorul lui masă rotativă este posibil să se construiască o serie de rapoarte analitice diferite, în care una dintre tăieturi va fi „Articolul UU” analitic. De exemplu, așa:

Fig.2.4. Raport de cost al atelierului de supape

Mapare versus VLOOKUP()

Mulți utilizatori sunt familiarizați și folosesc funcția VLOOKUP() în astfel de situații. Cu toate acestea, funcția VLOOKUP() funcționează bine numai pe volume mari date, în timp ce forma dată face față bine procesării tabelelor Excel, chiar dacă aveți, să zicem, 5000 de rânduri în cartea de referință și 300.000 de rânduri pe pagina principală. Încercați să verificați și veți vedea că VLOOKUP () eșuează pe astfel de volume. În plus, funcția VLOOKUP() creează o încărcare semnificativă pe Excel, forțându-l să efectueze volume mari de calcule. Formularul de mapare evită acest dezavantaj: rulează o singură dată, durează câteva secunde (pentru volume mari de minute) și după aceea fără încărcări suplimentare pe fisier Excel nu mai este creat.

Companiile care folosesc Excel în scopul transformării raportării văd economii tangibile în pregătirea rapoartelor IFRS. Dacă volumele de tranzacții permit procesarea acreditărilor în foi de calcul, este recomandabil să folosiți Excel

Tabelele Excel, pe lângă acuratețea aritmetică și claritatea procedurilor de transformare, vă permit să generați date pentru analiză economică activități financiare bazate pe rezultate IFRS, care transformă modelul de raportare într-un instrument de management.

Etapa pregătitoare a transformării raportării

În etapa pregătitoare, se face o analiză a diferențelor specifice dintre IFRS aplicabile unei companii date și practicile contabile RAS. Trebuie remarcat faptul că este inadecvat să pornim de la regulile contabilității rusești, deoarece în acest caz va fi dificil să scapi de „prioritatea formei față de conținut” - ar trebui să începem cu o analiză a companiei în ansamblu. și activitățile sale din punctul de vedere al IFRS.

Standardele internaționale relevante pentru fiecare afacere ar trebui incluse în politica contabila conform IFRS. De exemplu, este puțin probabil ca o entitate de tranzacționare să folosească instrumente financiare complexe sau prevederile IAS 41 Agricultură și companie privata nu este obligat să prezinte rezultatul pe acțiune în conformitate cu IAS 33 Rezultatul pe acțiune. Procedura de formare a politicilor contabile ar trebui să vizeze nu numai crearea de reguli contabile și memorandumuri în conformitate cu IFRS, ci și de pregătirea unui bloc de note direct la situațiile IFRS care să conțină principalele aspecte ale politicilor contabile care trebuie dezvăluite în conformitate cu IAS. 1 „Prezentare situații financiare”.

Pe baza politicii contabile IFRS primite, este necesar să se identifice discrepanțe în estimările și principiile aplicate în RAS și să se alcătuiască o listă și reguli pentru calcularea principalelor ajustări de transformare, precum și o listă. Informații suplimentare necesare în scopurile IFRS, dar nu sunt luate în considerare în conformitate cu cerințele legislației ruse.

Când aplicați pentru prima dată standardele internaționale în conformitate cu IFRS 1, ar trebui să fiți conștienți de excepțiile și simplificările permise de standard și că ulterior aceste relaxări încetează să se aplice.

Procesul de actualizare a politicii contabile IFRS, a listei de ajustări și a listei de informații suplimentare ar trebui să fie în desfășurare, deoarece cerințele IFRS și ale legislației ruse sunt în mod constant suplimentate.

Maparea planului de conturi pentru transformarea raportării

Mapping - din limba engleză mapping (corespondență, precum și transformare) este o procedură de înregistrare a datelor în mai multe sisteme de coordonate, în cazul nostru, conversia soldurilor și cifrei de afaceri generate în conformitate cu planul de conturi RAS în structura planului de conturi conform planului de conturi. la IFRS (tabelul 1).

Tabelul 1. Exemplu de mapare a planului de conturi

Câteva cuvinte despre întocmirea planului de conturi propriu-zis conform IFRS.

• Fiecare indicator IFRS trebuie să aibă un unic cod digital, în cazuri extreme, format alfanumeric, strict definit. Însumarea indicatorilor în modern versiuni Excel poate chiar și din motive textuale, totuși, în acest caz, riscul distorsionării datelor în cazul unei simple greșeli de scriere crește. Pentru a minimiza erorile, se folosesc directoare și liste derulante cu coduri și nume de conturi și analiști, precum și formulele SUMIF și VLOOKUP care rezumă date cu caracteristici specificate, și anume coduri unice.
• Ierarhia planului de conturi ar trebui să permită gruparea datelor nu numai pe elemente, ci și pe rânduri din formularul de raportare și note. Să presupunem că articolul „Clădiri și structuri - Costul inițial”, pe lângă codul propriu, ar trebui să conțină printre analiști și codul de linie al situației poziției financiare (denumit în continuare bilanţ) și codul tabelului de note. , care va permite completarea formularelor și a notelor de raportare tabelare folosind formule Excel.
• Fiecare secțiune a formularelor de raportare din planul de conturi trebuie să conțină rezervă linii goale- acest lucru face posibilă ajustarea flexibilă a planului de conturi fără a reconfigura formulele și, de asemenea, vă permite să nu încălcați principiul comparabilității datelor. Este recomandabil să se prevadă spațiu pentru noi secțiuni, de exemplu, în cazul în care societatea anterior nu avea investiții imobiliare, dar planuri de conducere pentru a crea sau achiziționa bunuri imobiliare pentru închiriere. În acest caz, liniile gratuite sunt pur și simplu completate și codurile de raportare sunt introduse, iar Excel agregează automat indicatorii.
• Este necesar să se păstreze un istoric al modificărilor aduse cartografierii (de regulă, pe baza unui memorandum sau a unui alt document metodologic administrativ) indicând motivul, persoana responsabilă și datele la care modificările vor intra în vigoare. Acest lucru este important atât pentru formarea de date comparabile de la o perioadă la alta, cât și pentru promovarea auditului.

Trebuie remarcat faptul că cu cât un analist conține mai mult plan rusesc conturi, cu atât este mai ușor să faceți mapările și ajustările de reclasificare necesare datorită diverse principii agregarea datelor în RAS și IFRS. Prin urmare, ori de câte ori este posibil, planul de conturi al RAS și analiticele acestuia ar trebui să fie cât mai aproape de nevoile IFRS pentru a crește eficiența procesului de transformare și a reduce costurile.

Colectarea informațiilor necesare pentru completarea modelului transformațional.În această etapă se colectează date privind soldul conturilor de sold și se completează rulajele conturilor de venituri-cheltuieli pentru perioada de raportare, se completează bilanțul inițial și contul de venit.

Concomitent cu acest proces sunt analizate tranzacții semnificative, litigii, noi contracte majore, dezvăluiri suplimentare. Ar trebui elaborată o listă reglementată de informații suplimentare, precum și a celor responsabili pentru pregătirea datelor relevante și a termenelor limită pentru implementare.

Lista prezentată în Tabelul 2 poate fi atât redusă dacă societatea nu are anumite operațiuni, cât și extinsă semnificativ. De regulă, în activitățile companiei, rareori apar modificări care presupun ajustări suplimentare la IFRS. Prin urmare, cea mai amănunțită analiză se face în timpul cunoașterii inițiale cu afacerea și numai atunci sunt urmărite schimbările semnificative. Astfel, în majoritatea cazurilor, companiile ar trebui să facă aproximativ zece până la douăzeci de ajustări de transformare, care pot fi reglementate de instrucțiuniși sunt consacrate în documentul „Procedura de Contabilitate a Ajustărilor de Transformare”.

Tabelul 2. Lista indicativă de informații suplimentare

Toate ajustările ar trebui făcute sub forma unui document de lucru, cum ar fi o situație contabilă. Documentul de lucru ar trebui să conțină bazele metodologice și premisele faptice pe baza cărora au fost efectuate anumite ajustări, precum și calculele în sine. De asemenea, este necesar să se stabilească proceduri de control care vizează verificarea corectitudinii calculelor, reconcilierea datelor din documentele de lucru și modelele de transformare, precum și corectitudinea înregistrărilor.

Etapa de formare a ajustărilor primite. Ajustările interne sunt generate la prima aplicare a IFRS, precum și la achizițiile de noi companii, care trebuie evaluate la valoarea justă.

Pentru început, posturile din bilanţ și din contul de profit și pierdere sunt regrupate. Acestea sunt așa-numitele ajustări de reclasificare. Principalele ajustări de reclasificare includ decongelarea sau decongelarea creanțelor, datoriilor și avansurilor, reclasificarea cheltuielilor amânate, separarea activelor și pasivelor pe termen scurt și pe termen lung, transferul depozitelor cu o scadență mai mică de 90 de zile în numerar. , și o alocare mai detaliată a veniturilor și cheltuielilor către conturile corespunzătoare, în cazul în care o astfel de muncă nu a fost efectuată în etapa de cartografiere (tabelul 3).

Tabelul 3. Exemplu de tabel de reclasificare

Următorul bloc de ajustări este corecțiile care afectează valoarea elementelor din bilanț, precum și veniturile și cheltuielile. Acestea nu trebuie confundate cu ajustările de reclasificare, deoarece numai ajustările estimate afectează impozitele amânate IFRS.

În practică, cele mai semnificative sume de ajustări sunt legate de evaluarea activelor la valoarea justă - imobilizări corporale (în special în cazurile în care societatea deține fonduri vechi) și imobilizări necorporale. Este imposibil să calculați astfel de ajustări pe cont propriu, deoarece acest lucru necesită date dintr-un raport de examinare efectuat de un evaluator calificat. De exemplu, fără cunoștințe și experiență speciale, este imposibil să se determine costul baza de clienti, care ar trebui recunoscută ca imobilizare necorporală conform IFRS atunci când o companie este achiziționată. Doar după obținerea datelor privind evaluarea sumei juste a costului inițial, gradul de amortizare, restul viata utila de utilizare, registrele activelor fixe și ale activelor necorporale se formează conform IFRS. Contabilitatea activelor fixe și a activelor necorporale poate fi efectuată ca în program separat, iar în foi de calcul, când se ține un registru al mijloacelor fixe în Excel, se reflectă încasări, modernizări, cedări de obiecte, amortizarea se calculează la costul recunoscut conform IFRS.

Cel mai simplu mod de a calcula ajustările este de a compara datele RAS și IFRS și de a determina discrepanța dintre acestea. Aceste sume formează corecția (tabelul 4).

Tabelul 4. Calculul ajustării pentru reevaluarea imobilizărilor corporale la valoarea justă

Pe lângă reflectarea reevaluării, pentru activele fixe și imobilizările necorporale, poate fi necesară recalcularea sumei dobânzii capitalizate, întrucât RAS și IFRS conțin abordări diferite la determinarea valorii capitalizării.

Prevederile IAS 36 Deprecierea activelor sunt, de asemenea, mai axate pe testarea imobilizărilor corporale și a imobilizărilor necorporale, a căror valoare trebuie ajustată atunci când există un indiciu de depreciere.

În cazul în care o entitate utilizează contracte de leasing financiar în operațiunile sale (așa cum sunt interpretate de IFRS), ajustările pot afecta, de asemenea, valoarea imobilizărilor corporale și costurile de amortizare în corespondență cu datorii de leasing financiar și cu dobânzile datorate pentru fondurile împrumutate.

O atenție deosebită ar trebui acordată ajustărilor legate de actualizare (cum ar fi, de exemplu, în cazul contractelor de leasing financiar pe termen lung, când atât costul imobilizărilor corporale, cât și al pasivelor din contractele de leasing financiar sunt estimate pe baza actualizării) . IFRS impune actualizarea oricăror active și datorii pe termen lung:

• valoarea veniturilor atunci când plata este amânată în timp;
• valoarea unui provizion sau provizion pe termen lung în conformitate cu IAS 37 Provizioane, datorii contingente și active contingente;
• costul unei investiții într-o filială în care există o plată amânată pentru acțiuni;
• componenta de datorie a obligațiunilor convertibile pe termen lung;
• valoarea recuperabilă a unui activ financiar contabilizat la cost amortizat atunci când este testat pentru depreciere etc.

Cele mai frecvente ajustări includ:

• asupra stocurilor (stergerea stocurilor nelichide ca pierderi, crearea unei rezerve pentru deprecierea stocurilor, anularea lipsurilor și pierderilor din deteriorarea valorilor, precum și unele tipuri de cheltuieli ale perioadelor viitoare);
• privind decontările cu personalul (ajustări ale rezervelor pentru concedii, crearea unei rezerve pentru remunerarea viitoare, decontări în cadrul planurilor de pensii);
• Ajustări de tip cutoff (scăderea veniturilor amânate, acumularea sau anularea suplimentară a veniturilor și cheltuielilor din perioada de raportare care nu au fost reflectate în RAS din cauza lipsei documentelor sau a diferențelor în abordarea recunoașterii momentului transferului riscurilor și recompense, în corespondență cu conturile de decontare cu contrapărțile);
• pentru creanțe și datorii, precum și împrumuturi și împrumuturi (înregistrate la cost amortizat folosind metoda dobânzii efective, ajustarea provizioanelor pentru creanțe îndoielnice);
• privind investițiile financiare (recunoașterea unei cote din profitul sau pierderea asociaților, ajustări ale costului investițiilor financiare, în funcție de care se poate determina valoarea curentă de piață etc.).

După formarea tuturor ajustărilor de decontare, se determină valoarea ajustării impozitului pe venit amânat.

Desigur, nu sunt enumerate toate ajustările posibile, deoarece scopul este de a demonstra cum se formează grupul de ajustări primite și cum ar trebui reportate ajustările de la an la an (Tabelul 5).

Tabelul 5. Formarea listei de ajustări primite

În continuare, ținând cont de ajustările primite, se efectuează întocmirea bilanţului, a contului de profit şi pierdere, a situaţiei modificărilor capitalurilor proprii, a situaţiei fluxurilor de numerar în format IFRS, precum şi întocmirea explicaţiilor pentru raportare.

Ajustările primare sunt utilizate pentru a transfera în situațiile perioadelor următoare ca ajustări primite. Există două moduri de transfer:

• ajustările conturilor de bilanț sunt luate în considerare în corespondență cu contul rezultatului reportat;
• ajustările la conturile de venituri/cheltuieli în corespondență cu contul de rezultat reportat sunt inversate.

Alegerea metodei de transfer afectează doar tehnica de calcul a ajustărilor curente pentru următoarele perioade de raportare, rezultatul final va fi același, cu toate acestea, nu va mai fi posibilă modificarea modelului de calcul al ajustărilor, deci ar trebui să determinați în prealabil metoda cea mai convenabilă și ține-te de ea.

Etapa de generare a ajustărilor pentru perioadele de raportare ulterioare. Ajustările tipice în următoarele perioade de raportare trebuie efectuate ținând cont de ajustările primite. Mecanismul de generare a datelor IFRS este următorul - în tabele Excel completat pagina cu pagina:

• cartografierea soldurilor și cifrelor de afaceri conform RAS în solduri și cifrelor de afaceri conform IFRS;
• ajustări de reclasificare;
• ajustări primite (excluzând reclasificările perioadei anterioare);
• ajustări ale perioadei curente (calculate în documente de lucru separate, ținând cont de ajustările acumulate primite).

Apoi, folosind formulele SUMIF, datele sunt trase pe foaia de rezumat (vezi Tabelul 6).

Tabelul 6. Formarea datelor IFRS în modelul de transformare

Datele IFRS (coloana 8) se obțin prin însumarea datelor RAS inițiale, reclasificare, introducere și ajustări curente. În următoarea etapă, folosind și formula „SUMMESLI”, indicatorii IFRS gata pregătiți sunt agregați pe paginile rapoartelor (bilanț, declarație de profit) pe coduri de linii ale formularelor de raportare în conformitate cu codul de formular de raportare atribuit (tabelul 7). . Completați în același mod forme tabelare note, formule de control și reconciliere sunt prescrise între tabelul de transformare, formulare de raportare și note, modificarea rezultatului reportat pentru perioada este comparată cu soldurile de deschidere și de închidere pe indicator (sunt posibile diferențe în valoarea dividendelor acumulate).

Tabelul 7. Exemplu de utilizare Funcții Excel"SUMMESLI"

După cum putem vedea, Excel vă permite să generați destul de simplu și vizual date IFRS prin transformare. În practică, sunt folosite și alte abordări pentru completarea tabelelor de transformare, de exemplu, ca o tablă clasică de șah. Cu toate acestea, dacă sunt multe corecții, se obțin fișiere greoaie și crește riscul erorilor tehnice; în plus, devine dificilă analizarea corecțiilor acumulate în mai multe perioade. Indiferent de modelul de transformare utilizat, există recomandări universale pentru lucrul cu Excel: stocarea datelor trebuie să fie organizată în mod fiabil și protejată de acces neautorizat servere crearea automată copii de rezervă fișierele de lucru principale și salvarea automată în procesul de lucru, arhivarea regulată atât a datelor primare, cât și a modelelor finale, urmărirea modificărilor la fișiere și menținerea unui fișier de stare rezumat (foaia de control) care conține informații despre pașii necesari implementarea transformării și gradul de implementare a procedurilor stabilite.

Clasele recomandate trebuie să declare o coloană cheia principalaîntr-un tabel de bază de date. Majoritatea claselor ar trebui să-și descrie, de asemenea, propriile proprietăți în stil JavaBeans, inclusiv identificatorul unic al entității. Element în fișierul de mapare, ei vor defini maparea acestui câmp unic la o coloană de tabel care acționează ca cheie primară.

(5)

Dacă atributul nume nu este specificat, se presupune că clasa nu are nicio proprietate de identificare.

Atributul valoare nesalvată este important! Dacă proprietatea dvs. implicită de identificare a clasei nu este nulă, trebuie să setați atributul „unsaved-value” la valoarea corespunzătoare.

Există o declarație alternativă pentru a accesa date vechi cu chei compuse. Descurajăm cu tărie utilizarea cheilor compuse în alte cazuri.

5.1.4.1. generator

Element copil obligatoriu „a definește o clasă Java folosită pentru a genera identificatori unici pentru instanțe de clase pesimiste. Un element este utilizat dacă este necesar. Pentru a transmite parametri pentru inițializarea sau configurarea unei instanțe de generator.

uid_table next_hi_value_column

Toate generatoarele implementează interfața net.sf.hibernate.id.IdentifierGenerator. Este o interfață foarte simplă; multe aplicații pot folosi propriul generator personalizat de implementare. Indiferent, Hibernate include multe generatoare încorporate. Mai jos sunt numele scurte (etichete) pentru generatoarele încorporate:

Creştere

generează identificatori tip lung, scurt sau int, unic numai atunci când niciun alt proces nu adaugă date la același tabel. Nu utilizați într-un cluster.

Suportă coloane de identitate în DB2, MySQL, MS SQL Server, Sybase și HypersonicSQL. Tipul de returnare al identificatorului este lung, scurt sau int.

Utilizează secvența în DB2, PostgreSQL, Oracle, SAP DB, McKoi sau generator în Interbase. Tipul de returnare al identificatorului este lung, scurt sau int.

Utilizează un algoritm hi/lo pentru a genera eficient identificatori care sunt de tip long, short sau int, necesită un nume de tabel și de coloană (hibernate_unique_key și, respectiv, next_hi) ca sursă a valorilor hi. Algoritmul hi/lo generează identificatori care sunt unici numai pentru bazele de date individuale. Nu utilizați acest generator pentru conexiuni JTA sau conexiuni personalizate.

folosește un algoritm hi/lo pentru a genera identificatori de tip long, short sau int, folosind o secvență de bază de date.

Utilizează un algoritm UUID de 128 de biți pentru a genera identificatori de șir care sunt unici în rețea (folosind o adresă IP). UUID este un șir de 32 de caractere care conține reprezentarea hexazecimală a unui număr.

folosește același algoritm UUID, dar șirul atunci când se utilizează acest generator este format din 16 (unele) caractere ANSII. Nu utilizați cu PostgreSQL.

selectează identitatea, secvența sau hilo, în funcție de capacitățile bazei de date utilizate.

permite aplicației să seteze ea însăși identificatorul de obiect înainte de a apela metoda save().

este folosit identificatorul altui obiect asociat. Folosit de obicei împreună cu asociere prin cheie primară.

5.1.4.2. Algoritm Hi/Lo

Generatoarele hilo și seqhilo oferă două implementări alternative ale algoritmului hi/lo, abordarea preferată pentru generarea de identificatori. Prima implementare necesită un tabel „special” în baza de date pentru a stoca următoarea valoare „hi”. A doua implementare folosește consistența (în stilul Oracle), în bazele de date care le suportă.

hi_value următoarea_valoare 100 hi_value 100

Din păcate, nu puteți utiliza hilo atunci când vă furnizați conexiunea la Hibernate și nici nu îl puteți utiliza într-o configurație când Hiberante utilizează o sursă de date de server de aplicații gestionată de JTA. Hiberante trebuie să poată primi valoarea „hi” într-o nouă tranzacție. abordare standardîn EJB, este să folosiți bean-ul fără stat de sesiune pentru a implementa algoritmul hi/lo.

5.1.4.3. Algoritmul UUID

Nu încercați să utilizați uuid.string în PostgreSQL.

5.1.4.4. Secvențe și coloane de identitate

Puteți utiliza generatorul de chei de identitate pentru bazele de date care acceptă coloane de identitate (DB2, MySQL, Sybase, MS SQL). Pentru bazele de date care acceptă secvențe, puteți utiliza stilul secvenței pentru a genera chei. Ambele strategii necesită două instrucțiuni SQL pentru a insera un nou obiect în baza de date.

uid_sequence

Pentru a dezvolta aplicații multiplatforme, utilizați strategia nativă. Va folosi strategii de identitate, secvență și hilo în funcție de capacitățile bazei de date cu care lucrează în prezent Hibernate.

5.1.4.5. Setați identificatori

Dacă doriți ca aplicația să atribuie ea însăși identificatori, puteți utiliza generatorul atribuit. Acest generator special folosește identificatori care sunt setați de aplicație. Pentru a face acest lucru, aplicația setează identificatorul în proprietatea corespunzătoare a obiectului. Fiți foarte atenți când utilizați această opțiune pentru a seta cheile (în cele mai multe cazuri, această soluție semnalează un design prost al aplicației).

Datorită naturii sale inerente, entitățile care folosesc acest generator nu pot fi salvate prin metoda Session.saveOrUpdate(). În schimb, trebuie să spuneți explicit lui Hibernate dacă obiectul trebuie creat sau actualizat apelând metodele adecvate pe obiectul Session: save() sau update() .

5.1.5. id-compozit

......

Pentru tabelele cu chei compuse, puteți mapa mai multe proprietăți de clasă ca proprietăți de identificare a obiectelor. Element acceptă mapările de proprietăți folosind elemente copil și .

Clasa dvs. persistentă trebuie să suprascrie metodele equals() și hashCode() pentru a implementa echivalența identificatorului compus. De asemenea, trebuie să implementeze interfața Serializable.

Din păcate, capacitatea de a specifica identificatori compuși implică faptul că obiectul persistent este identificatorul. Nu există o prelucrare mai convenabilă decât prin obiectul însuși. Trebuie să creați singur o entitate de clasă persistentă și să setați proprietatea de identificare a acesteia înainte de a încărca() starea persistentă asociată cu identificatorul compus dat. Descriem o modalitate mai adecvată, în care identificatorii compoziți sunt implementați de o clasă separată, în Secțiunea 7.4, „Componente ca identificatori compuși”. Atributele descrise mai jos se aplică numai metodei alternative:

nume (opțional): O proprietate de tip bean care conține un identificator compus (vezi secțiunea următoare).

clasă (opțional, implicit tipul proprietății este determinat prin reflecție): o componentă a acestei clase este utilizată ca identificator compus (vezi secțiunea următoare).

unsaved-value (opțional, implicit este none): dacă este setată la oricare, aceasta indică faptul că entitățile de tranzit sunt tratate ca noi.

5.1.6. discriminator

Element necesar pentru persistența polimorfă folosind strategia de mapare a ierarhiei tabelă pe clasă. Acest element declară o coloană discriminatoare, care determină dacă o înregistrare din tabel corespunde unei anumite clase din ierarhie. Discriminatorul poate fi unul dintre următoarele tipuri: șir, caracter, întreg, octet, scurt, boolean, da_nu, adevărat_fals.

Valorile corespunzătoare ale coloanei discriminatorului pentru fiecare clasă sunt specificate în atributul discriminator-valoare pentru elemente și .

Atributul forță este util numai dacă tabelul conține înregistrări cu valori suplimentare de discriminare care nu apar în clasa persistentă. De obicei, acest atribut nu este folosit.

5.1.7. versiune (optional)

Element reflectă faptul că tabelul conține înregistrări marcate cu o versiune. Acest lucru este util mai ales dacă intenționați să utilizați tranzacții lungi(vezi mai jos).

Numerele versiunilor pot fi lungi, întregi, scurte, marca temporală sau calendar.

5.1.8. marca temporală (opțional)

Element indică faptul că tabelul conține înregistrări marcate de timp. Acest element acționează ca o alternativă la marcatorii de versiune. Marcajele de timp sunt prin definiție o implementare mai puțin sigură a blocării optimiste. Cu toate acestea, uneori o aplicație folosește marcaje temporale în alte scopuri.

notă: articol este echivalent cu elementul .

5.1.9. proprietate

Element Declara o proprietate persistentă, în stil JavaBeans, a unei clase.

valoarea proprietății tip poate fi una dintre următoarele:

Numele tipului Hibernate subiacent (de exemplu, întreg, șir, caracter, dată, timestamp, float, binar, serializabil, obiect, blob).

Numele clasei Java (de exemplu, int, float, char, java.lang.String, java.util.Date, java.lang.Integer, java.sql.Clob).

Numele unei clase derivate din PersistentEnum (de exemplu, de exemplu.Color).

Numele clasei Java care urmează să fie serializată.

Numele clasei personalizate (de exemplu, com.illflow.type.MyCustomType).

Dacă nu specificați o valoare pentru proprietatea tip, Hibernate va folosi reflectarea asupra proprietății specificate pentru a se potrivi cu tipul Hibernate corespunzător. Hibernate va încerca să determine numele clasei proprietății returnate de metoda get() folosind regulile 2, 3, 4 în această ordine. Cu toate acestea, acest lucru nu este întotdeauna suficient. În unele cazuri, mai trebuie să specificați atributul tip. (De exemplu, pentru a distinge între Hibernate.DATE și Hibernate.TIMESTAMP sau pentru a specifica un tip personalizat.)

Atributul de acces vă permite să controlați modul în care Hibernate setează metoda de acces la câmp în timpul rulării. În mod implicit, Hibernate apelează metode de obținere/setare pentru a accesa câmpul. Dacă setați access="field" atunci Hibernate va ocoli metodele get/set și va accesa câmpul direct folosind reflectarea. Puteți specifica propria strategie de acces specificând o clasă care implementează interfața net.sf.hibernate.property.PropertyAccessor.

5.1.10. multi-la-unu

O relație normală cu o altă clasă persistentă este declarată folosind elementul multi-la-unu. În termeni relaționali, aceasta este o asociere multi-la-unu. Este de fapt doar o referire la un obiect.

Atributul cascadă poate lua următoarele valori: all, save-update, delete, none. Setarea unei alte valori decât niciunul va determina anumite operații asupra obiectului asociat (copil). Vedeți „Cicul de viață al obiectului” de mai jos.

Atributul outer-join poate lua următoarele trei valori:

auto (implicit) preia obiectele asociate folosind unirea exterioară dacă clasa asociată nu are proxy.

true Preluați întotdeauna obiectele asociate utilizând îmbinarea exterioară.

false Nu recuperați niciodată obiectele asociate utilizând îmbinarea exterioară.

O declarație tipică de asociere multi-la-unu arată astfel

Atributul property-ref ar trebui să fie utilizat numai pentru a lega date vechi atunci când cheia externă se referă la valoarea unică a unui tabel asociat, alta decât cheia primară. Aceasta este o decizie relațională periculoasă. De exemplu, este posibil ca clasa Product să aibă un număr unic de secvență care nu este o cheie primară. (Atributul unic controlează generarea DDL a Hibernate. Generarea se face folosind utilitarul SchemaExport.)

Maparea pentru un articol de comandă poate folosi:

De fapt, acest lucru este foarte descurajat.

5.1.11. unu la unu

O asociere unu-la-unu cu o altă clasă persistentă poate fi declarată folosind elementul unu-la-unu.

Există două tipuri de asociații unu-la-unu:

relație prin cheie primară

relație prin cheie străină unică

Nu este nevoie de coloane suplimentare pentru a organiza o asociere a cheii primare; dacă două înregistrări sunt legate printr-o astfel de asociere, înseamnă că două înregistrări din două tabele au aceeași valoare a cheii primare. Prin urmare, dacă doriți să asociați două obiecte astfel încât să fie legate prin cheia primară, atunci trebuie să vă asigurați că ID-urile lor sunt atribuite aceleași valori!

Pentru o asociere de cheie primară, adăugați următoarea mapare pentru clasele Angajat și, respectiv, Persoană.

Acum trebuie să ne asigurăm că cheile primare ale înregistrărilor aferente din tabele sunt identice. Folosim un generator străin Hibernate special:

angajat ...

Instanței persistente a clasei Person i se atribuie aceeași valoare a cheii primare care este atribuită instanței clasei Employee la care face referire proprietatea angajat a clasei Person.

Ca o modalitate alternativă de a descrie o relație unu-la-unu de la Angajat la Persoană, următoarea notație poate fi utilizată printr-o cheie străină unică:

Această asociere poate fi bidirecțională după adăugarea următoarei expresii la maparea clasei Person:

5.1.12. component, component-dinamic

Element mapează câmpurile obiectului imbricat la coloanele din tabelul clasei părinte. Componentele își pot defini, la rândul lor, propriile proprietăți, componente sau colecții. Consultați „Componentele” de mai jos.

(5) ........

Etichete imbricate Mapează câmpurile componente cu coloanele tabelului.

Element permite element imbricat Care redă proprietatea componentei ca referință înapoi la obiectul părinte.

Element vă permite să utilizați Harta ca componentă, în care numele câmpurilor corespund cheilor Hărții.

5.1.13. subclasă

În cele din urmă, persistența polimorfă necesită ca fiecare subclasă a clasei de bază să fie declarată. Strategia de mapare a tabelului-pe-clasă-ierarhie (recomandată) utilizează elementul .

.....

Fiecare subclasă trebuie să-și declare propriile câmpuri și subclase persistente. Moștenirea proprietății permisă și din clasa de bază. Fiecare subclasă din ierarhie trebuie să definească o valoare-discriminatorie unică. Dacă această valoare nu este specificată, atunci numele de clasă complet calificat este folosit ca discriminator.

5.1.14. subclasa unită

Alternativ, o subclasă ale cărei obiecte sunt stocate într-un tabel separat (strategie de mapare tabel pe subclasă) este declarată folosind elementul .

.....

Această strategie de mapare nu necesită specificarea unei coloane discriminatoare. Cu toate acestea, fiecare subclasă trebuie să declare o coloană de tabel care conține identificatorul redat de element. . Maparea dată la începutul secțiunii poate fi rescrisă după cum urmează:

Starea persistentă constă din referințe la alte entități și instanțe de tipuri de valori. Valorile sunt primitive, colecții, componente și alte obiecte imuabile. Spre deosebire de entități, instanțele de tipuri de valori (în special, colecțiile și componentele) sunt păstrate și șterse atunci când sunt disponibile. Deoarece obiectele de tip valoare (și primitivele) sunt salvate și șterse împreună cu entitatea care le conține, acestea nu pot fi versionate independent. De asemenea, valorile nu au o identitate independentă și, prin urmare, nu pot fi împărtășite între două entități sau colecții.

Toate tipurile din Hibernate, cu excepția colecțiilor, acceptă semantica pointerului nul.

Până în acest moment, am folosit termenul „clasă persistentă” pentru a ne referi la entități. Vom continua să facem asta. Strict vorbind, nu toate clasele de persistență definite de utilizator sunt entități. De exemplu, o componentă este o clasă definită de utilizator cu semantică de tip valoare (componentele fac parte din entitățile care le conțin și sunt considerate câmpuri ale acelor entități).

5.2.2. Tipuri de valori de bază

Tipurile de bază pot fi împărțite aproximativ după cum urmează

întreg, lung, scurt, flotant, dublu, caracter, octet, boolean, da_nu, adevărat_fals

Mapări ale tipurilor Java primitive sau ale claselor wrapper la tipurile de coloane de tabel SQL corespunzătoare (dependente de furnizor). boolean, yes_no și true_false sunt notații alternative pentru tipurile Java boolean sau java.lang.Boolean.

Maparea java.lang.String la VARCHAR (sau Oracle VARCHAR2).

Maparea tipului java.util.Date și a subclaselor sale la tipurile SQL DATE, TIME și TIMESTAMP (sau echivalent).

Maparea tipului java.util.Calendar cu tipurile SQL TIMESTAMP și DATE (sau echivalent).

Maparea tipului java.math.BigDecimal la NUMERIC (sau Oracle NUMBER).

Maparea tipului de java.util.Locale, java.util.TimeZone și java.util.Currency la VARCHAR (sau Oracle VARCHAR2). Instanțele de localitate și monedă sunt mapate la codurile lor ISO. Instanțele TimeZone sunt mapate la ID-urile lor.

Maparea tipului java.lang.Class la VARCHAR (sau Oracle VARCHAR2). Clasa este afișată ca nume complet calificat.

Mapează matricele de octeți la tipul SQL binar corespunzător.

Afișează șiruri Java lungi în SQL CLOB sau TEXT.

Mapează tipurile Java serializabile la tipurile SQL binare corespunzătoare. De asemenea, puteți desemna ca tipul Hibernate serializabil să fie numele unei clase Java serializabile sau al unei interfețe care nu este un tip de bază și nu implementează interfața PersistentEnum.

Maparea tipului JDBC a claselor java.sql.Clob și java.sql.Blob. Aceste tipuri pot fi incomode pentru unele aplicații, deoarece obiectele blob și clob nu pot fi utilizate în afara tranzacțiilor. (În plus, șoferii acceptă aceste tipuri incomplet și în moduri diferite.)

Identificatorii unici de entitate și colecție pot fi de orice tip de bază, cu excepția celor binari, blob și clob. (De asemenea, sunt permise identificatorii compuși, vezi mai jos.)

Tipurile de valori de bază sunt descrise de constantele declarate în net.sf.hibernate.Hibernate. De exemplu, Hibernate.STRING reprezintă tipul șirului.

5.2.3. Tipuri enumerate persistente (enum)

Un tip enumerat este un idiom Java de bază atunci când o clasă are un număr constant (mic) de instanțe imuabile. Puteți crea tipuri de enumerare persistente prin implementarea interfeței net.sf.hibernate.PersistentEnum și definirea operațiunilor toInt() și fromInt():

pachet de ex; import net.sf.hibernate.PersistentEnum; clasă publică Color implementează PersistentEnum ( cod privat final int; privat Culoare (cod int) ( this.code = cod; ) public static final Culoare TABBY = culoare nouă (0); public static final Culoare GINGER = culoare nouă (1); public static final Culoare NEGRU = culoare nouă(2); public int toInt() (codul returnat; ) public static Culoare fromInt(cod int) ( comutator (cod) ( caz 0: returnează TABBY; caz 1: returnează GINGER; caz 2: returnează NEGRU; implicit: aruncă o nouă excepție RuntimeException ("Cod de culoare necunoscut"); ) ) )

Numele tipului Hibernate este pur și simplu numele clasei enumerate, în acest caz de ex.Color.

5.2.4. Tipuri de valori personalizate

Este relativ ușor pentru dezvoltatori să creeze tipuri de valori personalizate. De exemplu, este posibil să doriți să stocați proprietăți de tip java.lang.BigInteger în coloanele VARCHAR. Hibernare nu oferă un tip încorporat pentru aceasta. Dar definiția tipurilor personalizate nu se limitează la maparea proprietăților (sau a elementelor de colecție) la o singură coloană de tabel. Astfel, de exemplu, puteți avea o proprietate getName()/setName() de tip java.lang.String care este stocată în coloanele FIRST_NAME, INITIAL, SURNAME.

Pentru a implementa un tip de utilizator, implementați una dintre interfețele net.sf.hibernate.UserType sau net.sf.hibernate.CompositeUserType și declarați proprietatea folosind numele de clasă complet calificat al implementării tipului dvs. Examinați net.sf.hibernate.test.DoubleStringType pentru opțiunile disponibile.

Notă: utilizați etichete pentru a afișa proprietatea în mai multe coloane.

În timp ce bogăția tipurilor încorporate din Hibernate și a suportului pentru componente înseamnă că tipurile personalizate sunt rareori necesare, este totuși considerată o bună practică să folosiți tipuri personalizate ca clase (non-entități) pentru tipurile care sunt utilizate frecvent în aplicația dvs. De exemplu, clasa MonetaryAmount este un candidat bun pentru CompositeUserType, deși poate fi redată ca componentă. Motivația principală este abstractizarea. Cu tipurile personalizate, documentul dvs. de cartografiere va fi mai rezistent la posibilele modificări în viitor dacă modificați reprezentarea tipului de monedă.

5.2.5. Orice tip de mapare

Mai există un tip pentru afișarea proprietăților. Element de afișare declară o asociere polimorfă pentru clase din mai multe tabele. Acest tip de afișare necesită întotdeauna mai mult de o coloană. Prima coloană conține tipul de entitate asociat. Coloanele rămase conțin un identificator. Nu este posibil să se definească o cheie străină pentru un anumit tip de asociere, astfel încât această mapare nu este utilizată în mod normal pentru asocieri polimorfe. Ar trebui să utilizați această mapare numai în cazuri speciale (de exemplu, scrierea datelor eterogene, accesarea datelor sesiunii utilizator).

Atributul meta-type permite unei aplicații să specifice un tip personalizat care mapează valorile coloanei bazei de date la clase persistente ale căror proprietăți de identificare au tipul definit de id-type. Dacă meta-tipul returnează entități java.lang.Class, atunci nimic altceva nu este necesar. În caz contrar, atunci când este un tip de bază, cum ar fi șir sau caracter, trebuie să mapați valorile la clase.

..... .....

Vechea proprietate a obiectului, care are un loc separat în Hibernate 1.2, este încă acceptată, dar a fost depreciată.

5.3. Identificatori SQL citați

Puteți forța Hibernate să citeze identificatori în instrucțiunile SQL. Hibernate va urma regulile de citare conform dialectului SQL setat (de obicei ghilimele duble, dar paranteze pentru SQL Server și ghilimele din spate pentru MySQL).

...

5.4. Fișiere de afișare individuale

Puteți declara mapările subclaselor și subclaselor unite în documente separate, chiar în interiorul elementului hibernate-mapping. Acest lucru vă permite să extindeți ierarhia claselor prin adăugarea unui nou fișier de mapare. Cu această abordare, trebuie să specificați un atribut extins pe maparea subclasei care conține numele superclasei mapate anterior. Folosirea acestei caracteristici face ca ordinea în care sunt listate documentele de cartografiere să fie importantă.