Bmc Remedy It Service Management

FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI” TIMIȘOARA

UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA

FACULTATEA DE INGINERIE

DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI

FORMA DE ÎNVĂȚĂMÂNT – ZI

PROIECT DE DIPLOMĂ

CONDUCĂTOR ȘTIINȚIFIC

Prof. Dr .Ing. Titus Slavici

ABSOLVENT

Sârbulov Cosmin-Adrian

– 2016 –

FUNDAȚIA PENTRU CULTURĂ ȘI ÎNVĂȚĂMÂNT “IOAN SLAVICI” TIMIȘOARA

UNIVERSITATEA “IOAN SLAVICI” TIMIȘOARA

FACULTATEA DE INGINERIE

DOMENIUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI

FORMA DE ÎNVĂȚĂMÂNT – ZI

BMC Remedy IT Service Management

CONDUCĂTOR ȘTIINȚIFIC

Prof. Dr. Ing . Titus Slavici

ABSOLVENT

Sarbulov Cosmin-Adrian

2016

UNIVERSITATEA DIN ORADEA

FACULTATEA de Inginerie Electrică și Tehnologia Informației

DEPARTAMENTUL Calculatoare și tehnologia informației

TEMA _________________

Proiectul de Finalizare a studiilor a studentului________________________

1). Tema proiectului de finalizare a studiilor:_________________________________________

_______________________________________________________________________________

_______________________________________________________________________________

2). Termenul pentru predarea proiectului de diplomă__________________________________

3). Elemente inițiale pentru elaborarea proiectului de finalizare a studiilor ________________

________________________________________________________________________________

________________________________________________________________________________

4). Conținutul proiectului de finalizare a studiilor :____________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

5). Material grafic:________________________________________________________________

________________________________________________________________________________

________________________________________________________________________________

6). Locul de documentare pentru elaborarea proiectului de diplomă:

________________________________________________________________________________

________________________________________________________________________________

7). Data emiterii temei_____________________________________________________________

Coordonatori științifici

Prof. Dr. Ing. Titus Slavici

REFERAT

PRIVIND PROIECTUL DE DIPLOMĂ

A

ABSOLVENTULUI / ABSOLVENTEI : ……………………………………….

DOMENIUL Calculatoare și tehnologia informației

SPECIALIZAREA Calculatoare

PROMOȚIA 2016

Titlul proiectului …………………………………………………………………..

…..…………………………………………………………………………………………………

Structura proiectului ………………………………………………………………..

…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

…………………………………………………………………………………………………………………………………………………………………………………………………………………

Aprecieri asupra conținutului proiectului de DIPLOMĂ (finalizare a studiilor), mod de abordare, complexitate, actualitate, deficiențe

………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

Aprecieri asupra proiectului (se va menționa: numărul titlurilor bibliografice consultate, frecvența notelor de subsol, calitatea și diversitatea surselor consultate; modul în care absolventul a prelucrat informațiile din surse teoretice)

…………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

(se va menționa: opțional locul de documentare și modul în care absolventul a realizat cercetarea menționându-se contribuția autorului)

……………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

Concluzii (coordonatorul proiectului trebuie să aprecieze valoarea proiectului întocmit, relevanța studiului întreprins, competențele absolventului, rigurozitatea pe parcursul elaborării proiectului, consecvența și seriozitatea de care a dat dovadă absolventul pe parcurs)

……………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………………

Redactarea proiectului respectă ………………………………………………….cerințele academice de redactare (părți, capitole, subcapitole, note de subsol și bibliografie).

Consider că proiectul îndeplinește/ nu îndeplinește condițiile pentru susținere în sesiunea de Examen de LICENȚĂ (finalizare a studiilor) din IULIE 2016 și propun acordarea notei ………………

Oradea,

Data Conducător științific

Capitolul I: „BMC ITSM Remedy” – Repere Teoretice

ITSM provine de la „Information Technology Service Management” (Managementul Serviciilor din Tehnologia Informației). Acesta este un concept preluat din ITIL sau IT Infrastructure Library și este definit ca bună practică pentru gestionarea serviciilor. BMC a scris o suită de aplicații în familia Remedy care furnizează o serie de funcții sau procese ITIL predefinite.

BMC Remedy ITSM eficientizează și automatizează procesele din centrul de servicii IT, operațiuni de management al patrimoniului și managementul schimbărilor. De asemenea, vă permite să vă corelați serviciile comerciale cu infrastructura IT pentru a putea gestiona impactul schimbărilor tehnologice asupra afacerilor și schimbărilor comerciale asupra tehnologiei – în timp real și în viitor. În plus, puteți înțelege și optimiza experiența utilizatorului, echilibra investițiile actuale și viitoare în infrastructură și vedea eventualul impact asupra afacerii folosind un model de servicii în timp real Toate acestea vă ajută să gestionați ceea ce contează pentru a livra un Management al Serviciilor Comerciale (BSM).

Fiecare aplicație BSM conține consolele, formele, legăturile active, escaladările, flashboard-uri și așa mai departe, necesare pentru executarea funcțiilor sale de bază. Aplicațiile folosesc și mai multe module integrate și aplicații de suport care extind și îmbunătățesc aceste funcții de bază.

BMC Remedy ITSM eficientizează și automatizează procesele din centrul de servicii IT, operațiuni de management al patrimoniului și managementul schimbărilor. De asemenea, vă permite să vă corelați serviciile comerciale cu infrastructura IT pentru a putea gestiona impactul schimbărilor tehnologice asupra afacerilor și schimbărilor comerciale asupra tehnologiei – în timp real și în viitor. În plus, puteți înțelege și optimiza experiența utilizatorului, echilibra investițiile actuale și viitoare în infrastructură și vedea eventualul impact asupra afacerii folosind un model de servicii în timp real Toate acestea vă ajută să gestionați ceea ce contează pentru a livra un Management al Serviciilor Comerciale (BSM). Fiecare aplicație BSM conține consolele, formele, legăturile active, escaladările, flashboard-uri și așa mai departe, necesare pentru executarea funcțiilor sale de bază. Aplicațiile folosesc și mai multe module integrate și aplicații de suport care extind și îmbunătățesc aceste funcții de bază.

În Alcatel-Lucent, ITSM este principalul Sistem de Ticketing pentru Proiecte de Servicii Gestionate și un sistem conform cu procesul ITIL. Pentru folosirea Proiectelor de Servicii Gestionate, sistemul urmează Procesul Trouble 2 Resolve (T2R) pentru Managementul Incidentelor, Problemelor și Schimbărilor.

Mai jos se află o descriere a aplicațiilor din suită:

Service Desk

Service Desk conține Managementul Incidentelor și Managementul Problemelor. Aceste două unelte arată și se comportă similar dar deservesc funcții diferite.

Managementul incidentelor este cel mai bine definit ca fiind procesul prin care operațiunile normale de servicii sunt restaurate cât mai rapid posibil și pentru minimalizarea impactului asupra operațiunilor comerciale, astfel asigurând cel mai ridicat nivel posibil de calitate și disponibilitate a serviciului.

Managementul Problemelor este cel mai bine definit ca fiind efortul de rezolvare a cauzei de bază a incidentelor și astfel de minimalizare a impactului advers al incidentelor și problemelor asupra activității, acestea fiind cauzate de erori ale infrastructurii IT.

1.1. Managementul configurației și CMDB

Managementul Configurației este un proces care monitorizează toate elementele de configurare (CI – Configuration Items) dintr-un sistem. Acest proces este îndeplinit în mod normal prin fuzionarea datelor dintr-o serie de unelte de descoperire și surse de date existente într-o singură sursă de date denumită Configuration Management Database sau CMDB.

Folosind CMDB, puteți elabora relații și dependențe de date între Servicii, sisteme, hardware, rețea, persoane și alte componente ale infrastructurii.

Managementul Schimbărilor

Scopul Managementului Schimbărilor este să asigure că sunt folosite metode și proceduri standardizate pentru gestionarea eficientă a tuturor schimbărilor din infrastructură, pentru a minimaliza impactul incidentelor legate de schimbare și îmbunătăți operațiunile de zi cu zi.

Managementul calității serviciilor

Managementul calității serviciilor asigură identificarea, monitorizarea și analiza continuă a nivelurilor serviciilor IT specificate în acordurile privind calitatea serviciilor (SLAs). Managementul calității serviciilor asigură că există aranjamente cu furnizorii de suport IT interni și furnizorii externi în forma Acordurilor privind Nivelul Operațional (OLA) și Contractelor de Bază (UC). Procesul implică evaluarea impactului schimbării asupra calității serviciului și SLA. Procesul de management al calității serviciului este în strânsă relație cu procesele operaționale pentru controlul activităților. Rolul central al managementului calității serviciilor îl face locul central pentru stabilirea și monitorizarea valorilor contra unei valori de referință.

Managementul calității serviciului Remedy este foarte strâns integrat cu Managementul Incidentelor, Problemelor și Schimbării pentru a vă ajuta să definiți, gestionați și să raportați cu privire la Acordurile privind calitatea serviciului (acordurile cu clientul) și Acordurile privind Nivelul Operațional (obiective interne de servicii).

Managementul cunoștințelor

Managementul cunoștințelor este o unealtă BMC care se integrează unitar cu suita ITSM. Aceasta permite furnizorilor de suport să aducă soluții în baza de cunoștințe din Managementul Incidentelor, Problemelor sau Schimbărilor. Partajarea cunoștințelor în tot campusul va fi o unealtă foarte puternică.

1.2. Date de configurare

Datele de Configurare este o componentă esențială în proiectul centrului de servicii Remedy și toate aplicațiile Remedy ITSM. Folosind unelte administrative, se poate crea o secțiune izolată sau o „ocupație temporară” în sistem pentru organizația dvs. Echipa de suport Remedy a făcut deja asta pentru dvs.

Fiecare ocupare temporară este denumită drept o companie. Fiecare companie conține organizații de suport și grupuri de suport. Fiecare grup de suport are membri sau „furnizori de suport”. Ca și conducere funcțională a companiei dvs., veți fi responsabili pentru administrarea acestor date.

1.3. Consola locală de administrare

Consola locală de administrare este o aplicație personalizată pe care Alcatel a conceput-o pentru a permite unităților din toată compania să-și administreze propriile date de configurare. Contul Remedy va primi permisiuni speciale pentru ca dvs. să puteți accesa această consolă.

1.4. Interfață și orientări de mediu

Mediul de producție

Mediul de producție Remedy este folosit doar pentru satisfacerea nevoilor ITSM în stare constantă. Acesta nu este folosit pentru testarea schimbărilor și configurațiilor. Sistemul de producție procesează sute de mii de Incidente și alte date critice în fiecare an. Este folosit de sute de furnizori de suport din toată întreprinderea pentru monitorizarea și partajarea activității lor.

Pentru a putea accesa serverul de producție, se foloseste un navigator web cu acest URL, ca cel de mai jos:

http://global-itsm-css.de.alcatel-lucent.com:8080/arsys/shared/login.jsp?/arsys/home

Mediul de test

Mediul de test Remedy este pus la dispoziția tuturor partenerilor din campus în scopul testării. Acesta este accesat ușor ca și mediul de producție dar nu deține date în timp real sau date critice. Mediul de test este configurat în hardware și software să fie identic în majoritatea modurilor cu mediul de producție.

Schimbările aduse la datele de configurație pentru producție nu sunt mutate automat la test. Dacă doriți să aveți un mediu de test curent, este necesar să faceți modificări în ambele locuri. De două ori pe an, echipa de suport va programa o „reîmprospătare” a testului pentru a se asigura că acesta rămâne utilizabil în sincronizare cu producția.

Pentru a putea accesa serverul de test, se foloseste un navigator web cu acest URL, ca cel de mai jos:

http://149.204.78.16:8080/arsys/shared/login.jsp?/arsys/

Mediul de dezvoltare

Doar personalul de suport Remedy folosește mediul de dezvoltare Remedy. Funcția sa este să permită personalului de suport să dezvolte schimbări în sistem. Acesta nu este disponibil în prezent pentru comunitate.

1.5. Autentificarea în Remedy ITSM

Când vă autentificați pentru prima dată în sistem vi se va prezenta pagina de plecare – Home. Această pagină vă furnizează o serie de legături care vă duc la diferite componente ale suitei ITSM.

Deși sunt multe componente pe care le puteți accesa din pagina Home, acest document va folosi doar două aplicații: Consola locală de administrare și Consola de management al incidentelor.

1.6. Structura organizațională

Compania

Domeniul companiei este un container care definește o nouă „ocupare temporară” în suita de aplicații Remedy ITSM. Există multe setări, filtre și date de configurare specifice companiei.

În cadrul companiilor, definim două divizii logice (seturi de containere) care sunt folosite în două scopuri diferite, Organizații și Organizații de Suport. În fiecare dintre acestea există Departamente și Grupuri de Suport.

Înțelegerea Organizațiilor de Suport și Grupurilor de Suport

În mod tipic, ne „ridicăm” entitățile la nivel departamental, precum „Tehnologia Informației” atunci când creăm Organizații de Suport (vezi Figura „a”). Aceasta ne permite să creăm un număr nelimitat de grupuri de suport în acea organizație de suport.

Grupurile de suport joacă un rol major în definiția companiei dvs. Când domeniul Companiei și domeniile Organizațiilor de Suport sunt containere organizaționale, Grupurile de Suport sunt singurul loc unde pot fi atribuite Incidente. Nu puteți atribui incidente la o Organizație de Suport sau Companie.

Crearea Organizațiilor și Departamentelor

Pentru a crea o nouă organizație sau departament:

Deschideți Consola locală de administrare și în dreapta Organizației faceți click pe Create. Apare o fereastră cu titlul „Organization”.

Pentru a crea o nouă organizație, tastați numele în a doua căsuță etichetată cu Organization.

Pentru a crea un nou departament, tastați numele în a treia căsuță etichetată cu Department.

Revizuiți datele și prezentarea valorilor pe care le-ați introdus manual. Imediat ce aceste valori sunt aplicate la evidențe, realizarea modificărilor devine dificilă.

Faceți click pe butonul Add pentru a crea Organizația/ Departamentul introdus.

Dacă doriți să creați mai multe, repetați acești pași. Dacă nu, faceți click pe butonul Close.

Figura „a”

Crearea Organizațiilor de Suport și Grupurilor de Suport

Deschideți Consola locală de administrare și în dreapta Grupului de Suport faceți click pe Create. Apare o fereastră cu titlul „Support Group”.

Figura „b”

Pentru a crea o nouă organizație de suport, tastați numele în a doua căsuță etichetată cu Support Organization.

Pentru a crea un nou grup de suport, tastați numele în a treia căsuță etichetată cu Support Group.

În final, selectați cel mai potrivit nivel de suport pentru acest grup de suport din meniul derulant Support Group Role.

Revizuiți datele și prezentarea valorilor pe care le-ați introdus manual. Imediat ce aceste valori sunt aplicate la evidențe, realizarea modificărilor devine dificilă.

Faceți click pe butonul Add pentru a crea Organizația/ Departamentul introdus.

Dacă doriți să creați mai multe, repetați acești pași. Dacă nu, faceți click pe butonul Close.

Categorii operaționale

Categoriile operaționale sunt folosite pentru a vă îmbogăți datele de incident, cu scop în a vă ajuta să construiți rapoarte mai bune și a permite căutări mai detaliate. Funcțional, OpCats apare ca un meni pe trei niveluri, condus ierarhic cu fiecare conținut de meniu în funcție de meniul dinaintea sa.

Exemplu:

Cerere de Servicii

Cerere Standard

Cerere de Suport

Aceste valori sunt folosite pentru a vă întâmpina nevoile de raportare. Dacă nu aveți nevoi de raportare sau sunteți în curs de elaborare, cel mai bine așteptați și vedeți abordarea pentru crearea OpCats.

Notă: Dacă ștergeți un OpCat, acesta nu va mai fi disponibil pentru raportare

Adăugarea de noi categorii operaționale

Din pagina de plecare, deschideți consola locală de administrare.

Faceți click pe link-ul ce se găsește în partea dreaptă a etichetei Operation Categories. Apare o fereastră etichetată Operation Catalog.

Tier 1, 2 or 3? Decideți de nivel (tier) veți crea. Dacă creați un OpCat de nivel 3, puteți selecta nivelul corespunzător 1 și 2 din meniurile derulante.

Figura „c”

În mod tipic, lăsați starea la enabled, dar mai bine o schimbați la proposed până când sunteți gata să începeți folosirea noii categorii operaționale.

Adăugați o scurtă descriere.

Faceți click pe butonul Add.

Dacă doriți să creați mai multe, repetați acești pași. Dacă nu, faceți click pe butonul Close.

Persoane

Date despre clienți

Gestionarea persoanelor în Remedy este împărțită în două categorii majore, furnizori de suport și clienți. Mare parte din munca de definire a clienților este efectuată de Remedy printr-un import lunar din serverele director Alcatel. Toate persoanele noi cu intrare în director sunt importate în tabelul cu persoane Remedy în fiecare noapte. Importul se face o singură dată pe înregistrare astfel încât orice modificări la tabelul de persoane vor rămâne neschimbate și nu vor fi suprascrise de intrarea în director.

Datele clienților nu conțin compania în care se află aceștia. Dacă doriți ca clienții dvs. să apară în compania dvs., atunci trebuie să editați fiecare tabel de persoane pe rând. Din acest motiv, nu este recomandabil să adoptați această abordare la administrarea clienților.

Datele furnizorilor de suport

Adăugarea drepturilor de acces pentru un nou angajat

Evidența cu angajați trebuie să fie prezentă în directorul LDAP înainte de importul tabelului de persoane Remedy din seara anterioară.

Procesul de adăugare a furnizorilor de suport la grupurile dvs. de suport are loc în cinci minute imediat ce vă familiarizați cu acesta.

Există setări mai avansate pentru furnizorii de suport tehnic, care nu sunt acoperite în această secțiune. Aceste instrucțiuni acoperă practicile comune pentru setarea unui cont standard TSP.

Din consola de management incidente, faceți click pe My Profile în meniul din stânga.

Schimbați modul la căutare:

Dacă folosiți aplicații pe servere, faceți click pe binoclul din bara de meniu.

Dacă folosiți Midtier, faceți click pe butonul New Search din bara de unelte gri din partea de sus a formularului.

Căutați angajatul folosind una dintre următoarele metode:

a) Completați câmpurile First și Last Name sau folosiți parțiale. Amintiți-vă că Remedy ia în considerare majusculele și că prima literă a numelui și prenumelui trebuie capitalizată la căutare În fila de Login/ Access Details puteți căuta după NetID folosind câmpul Login ID.

Figura „d” Editați compania și organizația

În fila General, schimbați compania cu numele companiei dvs.

Selectați organizația și departamentul în care trebuie să fie situat utilizatorul dacă acesta aparține de configurația dvs.

Adăugați permisiuni

În fila Login/ Access Details, faceți click pe butonul Update Permission Groups.

Adăugați următoarele permisiuni:

Knowledge – Knowledge User

Incident – Incident User – floating

Problem – Problem Master – floating

Task – Task Manager

Rezultatele trebuie să se potrivească cu captura de ecran din figura”e”

Fig „e”

Adăugați accesul companiei

În fila Login/ Access Details, faceți click pe butonul Update Access Restrictions.

Adăugați-vă compania.

Fig „f”

Rezultatele trebuie să fie similare cu captura de ecran din figura „f”

Dacă vedeți oricare altă companie în această căsuță, eliminați-o.

În fila Login/ Access Details, setați tipul License la Floating. Lăsați setul Full Text License Type la None.

Deasupra filelor, schimbați valoarea câmpului Support Staff de la No la Yes.

Adăugați Grupuri de Suport

În final Support Groups, faceți click pe Update Support Groups and Roles.

Figura „i”

Selectați Organizația urmată de grupul de suport pe care doriți să îl adăugați. primul grup pe care îl adăugați va deveni grupul implicit al furnizorilor de suport.

Selectați Rolul Relației Membrului.

Faceți click pe Add.

Repetați procesul până când toate grupurile dorite sunt adăugate.

După ce ați adăugat grupurile, închideți butonul de la baza ferestrei Update Support Groups and Roles.

Salvați intrările

Ați terminat configurarea utilizatorului pentru un cont standard TSP. Faceți click pe butonul Save din bara de unelte gri din partea de sus a formularului înainte de a închide sau reveni la modul de căutare.

Informații suplimentare

Există unelte suplimentare pentru adăugarea utilizatorilor, inclusiv un tabel de permisiuni și o listă de verificări ce poate fi regăsită la finalul acestei secțiuni.

Eliminarea drepturilor de acces ale unui Angajat

Din consola de management incidente, faceți click pe My Profile în meniul din stânga.

Schimbați modul la căutare:

Dacă folosiți aplicații pe servere, faceți click pe binoclul din bara de meniu.

Dacă folosiți Midtier, faceți click pe butonul New Search din bara de unelte gri din partea de sus a formularului.

Căutați

Completați câmpurile First și Last Name sau folosiți parțiale. Amintiți-vă că Remedy ia în considerare majusculele și că prima literă a numelui și prenumelui trebuie capitalizată la căutare

În fila de Login/ Access Details puteți căuta după NetID folosind câmpul Login ID.

Editați compania și organizația

În fila General, schimbați compania cu Alcatel-Lucent. Trebuie să tastați această valoare. Aceasta nu poate fi selectată din meniu. Asigurați-vă că ștergeți câmpul Values din câmpurile Department și Organization.

Eliminați statusul Support Provider

În fila Login/ Access Details, copiați valoarea Login ID (NetID).

Deasupra filelor, localizați câmpul Support Staff și modificați această valoare la NO. Aceasta va șterge câmpul Login ID.

Lipiți sau tastați NetID înapoi în câmpul Login ID.

Faceți click pe butonul Save din bara de unelte gri din partea de sus a formularului înainte de a închide sau reveni la modul de căutare.

Figura „k”

1.7. Consolele Remedy

Consolele reprezintă principala interfață cu utilizatorul a aplicațiilor BMC Remedy ITSM. Sunt asigurate două tipuri de console: consolele de aplicații care asigură funcționalitate specifică aplicației și console comune care sunt folosite în rândul aplicațiilor. Consolele comune includ o consolă Overview care combină activitățile atribuite din toate aplicațiile într-un singur ecran și o consolă Requested concentrată pe utilizatori.

Când porniți suita BMC Remedy IT Service Management, pagina de plecare IT afișează consola Overview implicit. Cu toate acestea, puteți configura ceea ce doriți să vedeți în pagina de plecare IT. Dacă sunteți administrator de sistem, puteți configura pagina pentru toți utilizatorii. În caz contrar, puteți configura propriul utilizator pentru a vedea ecranele.

Consola Overview

Consola Overview furnizează o vedere asupra activităților atribuite prin multiple aplicații. De exemplu, dacă utilizatorii doresc să vadă toate cererile de incident, investigațiile problemelor și sarcinile ce le sunt atribuite, aceștia le pot vedea în consola Overview. Implementarea consolei Overview folosește un plug-in ARDDBC al sistemului AR BMC Remedy pentru a furniza o vedere consolidată a tuturor activităților atribuite din sursele de date din multiple aplicații fără a folosi replicarea datelor sau vederi SQL complexe care deviază de la API-uri. Arhitectura plug-in-ului este determinată de date. Formularele de configurație definesc modul în care este setat plug-in-ul, inclusiv ce formulare trebuie interogate, ce câmpuri trebuie selectate în câmpul tabelar și un formular ARDBC care efectuează interogarea.

Următoarea figură ilustrează zonele funcționale ale paginii de plecare IT.

Consolele de aplicație

BMC Remedy Asset Management, BMC Remedy Change Management, și BMC

Remedy Service Desk furnizează una sau mai multe console.

Aplicația BMC Remedy Asset Management furnizează mai multe console:

■ Asset Management

■ Contract Management

■ Purchasing

■ Software Asset Management (SAM)

■ Receiving

BMC Remedy Change Management furnizează o consolă de management al schimbărilor și

o consolă de management al versiunilor.

Consola de management al schimbărilor are două ecrane: una concentrată pe tehnicianul de suport și una pe manager. Consola Change Manager asigură și capacitatea de a schimba consola de suport să se concentreze pe sarcini sau cereri de schimbare.

BMC Remedy Service Desk asigură o consolă de management al incidentelor și o consolă de management al problemelor. Fiecare dintre aceste console furnizează un singur ecran pentru folosire de către analiști și manageri ai centrului de servicii.

Consola Requester

Pentru organizațiile care nu instalează BMC Service Request Management, consola Requester este o interfață prin care utilizatorii își pot crea și vizualiza cererile. Din consola Requester, utilizatorii pot crea o cerere care se depune la BMC Remedy Change Management sau BMC Remedy Incident Management. În funcție de modul în care este configurată aplicația, consola poate afișa cereri de incident și cereri de schimbare introduse în numele utilizatorului de către personalul de suport, în plus la cererile create de utilizator. Utilizatorii pot vizualiza cereri și răspunde la chestionare după ce cererea a fost rezolvată. Utilizatorii consolei Requester sunt în mod tipic angajați care au nevoie de asistență de la personalul de suport IT pentru implementarea unei schimbări sau rezolvarea unui incident. Cu toate acestea, utilizatorul poate să nu fie un angajat. Cei care nu sunt angajați pot fi utilizatori deoarece utilizatorii neînregistrați pot depune cereri de servicii. Tradiționat, după ce utilizatorul face un apel la un centru de asistență, un membru al personalului de suport înregistrează cererea. BMC Remedy Incident Management și BMC Remedy Change Management asigură auto-aprovizionarea utilizatorilor. Folosind consola Requester, utilizatorii pot depune, monitoriza și (în unele cazuri) rezolva cererile proprii. BMC Remedy Change Management și BMC Remedy Incident Management sunt pre-configurate să lucreze cu consola Requester. Cu toate acestea, o organizație poate decide să pună în indisponibilitate consola Requester.

Console de navigare, formulare și module

În majoritatea cazurilor, când deschideți console, formulare și module din pagina Home IT,

acestea se deschid în pagina Home IT. În mod similar, când deschideți un formular dintr-o consolă,

formularul înlocuiește consola în ecran. Dacă deschideți o înregistrare dintr-un formular, înregistrarea se deschide în ecranul care a fost ocupat de formular. De exemplu, dacă lucrați cu investigarea unei probleme („înregistrarea” inițială) și din înregistrarea inițială deschideți o cerere

de incident asociată, cererea de incident înlocuiește înregistrarea inițială în ecran. Dacă apoi deschideți o cerere de schimbare din cererea de incident, cererea de schimbare înlocuiește cererea de incident în ecran, și așa mai departe. Pentru a vă ajuta să monitorizați înregistrările pe care le vedeți și pentru a facilita navigarea, există o bară de marcaje în partea de sus a câmpului de vizualizare.

Bara de marcaje conține legături la înregistrările deschise din înregistrarea inițială. Dacă deschideți o înregistrare, coada de marcaje se extinde de-a lungul barei spre dreapta cu următoarea legătură. Dacă sunt peste șase legături în bara de marcaje, apar săgeți la unul sau ambele capete ale barei, care vă permit să derulați și să mergeți înainte în bară pentru a vedea legăturile care nu sunt încadrate.

Prima legătură din șirul de marcaje indică locul din care ați plecat. Acesta poate fi o consolă sau un formular. De exemplu, dacă deschideți o cerere de schimbare direct din pagina Home IT, prima legătură din bara de marcaje vă duce la cererea de schimbare. Ultima legătură corespunde cu înregistrarea aflată în prezent pe ecran. Dacă deschideți o legătură din stânga înregistrării afișate curent, sistemul trunchiază șirul de marcaje la acea legătură. Cu toate acestea, istoricul este reținut pentru a putea folosi săgețile înainte și înapoi din controalele de navigare pentru a merge printr-o înregistrare pe rând în bară. Există și un istoric al celor mai vizualizate înregistrări, pe care îl puteți folosi pentru a merge direct la o înregistrare. Faceți click pe săgeata orientată în jos pentru a deschide lista de istoric.

Dacă vizualizați o înregistrare din mijlocul șirului de marcaje și apoi mergeți la o altă înregistrare de tip inițial, sistemul șterge șirul de marcaje înainte din punctul în care ați scindat și începe un nou istoric de acolo, folosind noua înregistrare inițială ca punct de plecare. De exemplu: Deschideți investigația unei probleme, apoi deschideți o cerere de incident asociate și din cererea de incident deschideți o cerere de schimbare asociată. Dacă mergeți înapoi la înregistrarea cererii de incident și apoi deschideți o altă investigație, bara de marcaje nu va mai conține legătura

la cererea de schimbare. Șirul de marcaje arată acum investigația problemei inițială, cererea de incident și a doua investigație. Apoi arată orice înregistrări relevante pe care le deschideți ulterior din a doua investigație.

1.8. Bune practici

BMC Remedy ITSM prezintă o vedere de bune practici și o vedere clasică pentru formularele cheie. Ecranul de bune practici este o versiune îmbunătățită a formularului. În acest ecran, câmpurile cel mai folosite devin imediat vizibile. Puteți accesa funcționalități folosite mai puțin frecvent din secțiunile tabelare ale formularului sau din legăturile panoului de navigare. De exemplu, din formularul de cerere Incident, câmpul Templates este inclus în ecranul de bune practici pentru a încuraja folosirea șabloanelor.

Ecranul clasic este o vizualizare a formularelor similară cu cea prevăzută în versiunile anterioare. Acest ecran este furnizat pentru clienții care fac upgrade de la versiunile anterioare ale aplicațiilor BMC Remedy ITSM și care nu au adoptat încă ecranul de bune practici.

Ecranul de bune practici rămâne disponibil pentru fiecare dintre următoarele formulare:

■ Cerere de schimbare

■ Cerere de incident

■ Eroare cunoscută

■ Investigarea problemei

■ Cerere de eliberare

Capitolul II: „Module ISTM”

2.1. „BMC Remedy Change Management”

Folosind bunele practici a bibliotecii de infrastructură IT (ITIL – IT Infrastructure Library), BMC Remedy Change Management oferă organizațiilor IT capabilitatea de a gestiona schimbările, permițându-le acestora să:

■ Evalueze impactul, riscul și cerințele de resurse

■ Creeze planuri și să automatizeze funcții de aprobare pentru implementarea schimbărilor

■ Facilizeze distribuția corectă a versiunilor software și hardware, în timp ce minimalizează impactul asupra activității

Obiectivele de management al schimbării ITIL sunt să facă schimbările într-un mod controlat, să reducă riscurile la livrarea la termen a serviciilor IT și să alinieze obiectivele IT cu cele de activitate. Unele bune practici se concentrează pe aprobarea schimbării prin consiliul de aprobare a schimbărilor (CAB). BMC Remedy Change Management automatizează bunele practici descrise de ITIL, precum înregistrarea tuturor cererilor de schimbare, clasificându-le după posibilul risc la furnizarea serviciilor IT, direcționând cererile de schimbare, urmărind aprobările și respingerile, și comunicând detaliile și starea cererilor de schimbare. BMC Remedy Change Management asigură programarea și atribuirea sarcinilor și capabilități de raportare pentru revizuirea performanței și îmbunătățirea proceselor. Deoarece BMC Remedy Change Management este integrat cu BMC Atrium CMDB, acesta vă permite să corelați schimbările cu alte înregistrări, precum elemente de configurație (inclusiv servicii) și incidente.

Folosind BMC Remedy Change Management în combinație cu aceste aplicații, puteți aprecia sfera schimbării, puteți analiza costurile asociate cu schimbarea (în materie de timp și cheltuieli), efectua analiza de impact și de risc și puteți programa resursele necesare pentru ducerea la îndeplinire a schimbării. Folosind aplicația BMC Service Level Management, puteți defini țintele serviciului și măsura eforturile personalului de suport pe măsură ce aceștia implementează schimbările.

BMC Remedy Change Management vă oferă acces la Task Management

System (sistemul de management al sarcinilor), care este instalat și integrat ca parte din aplicație. BMC Remedy Change Management are următoarele caracteristici suplimentare:

■ Dependințe între cererile de schimbare, și o secvență ce poate fi definită, cu executare

■ Procese de aprobare pentru cererile de schimbare

■ Analiza riscurilor și impactului

■ Analiza costurilor și funcționalitatea managementului

■ Set extins de rapoarte predefinite

Procesele Management al Schimbărilor

Inițiere și înregistrare:

Inițierea și înregistrarea este etapa inițială a procesului de management al schimbărilor. Aceasta se concentrează pe înregistrarea scopului cererii de schimbare și pe obținerea informațiilor

suplimentare necesare pentru clasificarea și direcționarea cererii.

Principalele surse ale cererilor de schimbare sunt:

■ BMC Remedy Problem Management, inclusiv funcția de erori cunoscute

■ BMC Remedy Incident Management

■ BMC Service Request Management

Caracteristicile cheie din BMC Remedy Change Management create să sprijine această etapă a procesului includ:

■ Consola Requester

■ Atribuire automată sau cereri de schimbare la nivel de grup sau individual

■ Managementul versiunilor

■ Suport pentru clasificare pe multiple niveluri folosind cataloagele de produs și operaționale

■ Șabloane de schimbare de bune practici

Revizuire și autorizare

După ce cererea inițială a fost depusă, următoarea etapă logică este revizuirea și autorizarea.

Scopul acestei etape este ca managerul schimbării să analizeze cererea de schimbare, să furnizeze informații suplimentare pentru a adăuga mai mult context și, dacă este necesar, să inițieze procesul corespunzător de aprobare. Această etapă acționează ca un filtru inițial pentru a determina dacă cererea de schimbare trebuie să continue la următoarea etapă din proces.

Caracteristicile din BMC Remedy Change Management menite să sprijine această etapă a

procesului includ:

■ Consola de schimbare

■ Evaluarea riscurilor

■ Suport pentru corelarea CI-urilor din BMC Atrium CMDB

■ Analiza impactului schimbării

■ Integrare cu serverul BMC Remedy Approval Server

■ Confirmarea cererii

Planificare și programare

După ce cererea de schimbare a fost aprobată pentru începerea lucrării, următoarea etapă este să se planifice resursele și programele pentru a asigura un impact minim asupra mediului

de producție. După ce planificarea și programarea sunt finalizate, cererea de schimbare trece

printr-un alt proces de aprobare.

Implementare

Etapa de implementare constă din executarea planului și îndeplinirea

lucrării. Caracteristicile disponibile în BMC Remedy Change Management care sunt create să

sprijine această etapă a procesului includ:

■ Sistemul de management al sarcinilor

■ Managementul etapei sarcinilor

■ Automatizarea sarcinilor

■ Monitorizarea eforturilor

■ Costuri (reale)

■ Informații despre lucrare

Finalizare și închidere

Finalizarea și închiderea este etapa finală a unei cereri de schimbare. Această etapă indică dacă cererea de schimbare a fost finalizată cu succes sau dacă a fost anulată. Toate elementele de date (timp, cost și așa mai departe) sunt încheiate și înregistrate.

Procese de aprobare implicite

BMC Remedy Change Management vine cu procese implicite de aprobare create

out-of-the-box pentru utilizare globală. Aceste procese de aprobare bazate pe bune practici sunt

deja definite implicit pentru dvs. Aceste procese specifică ce stare apare în continuare

dacă o cerere este aprobară sau respinsă sau dacă nu sunt identificați factori de aprobare.

Procesul pre-configurat de aprobare pentru BMC Remedy Change Management

Câmpul read-only Next or Current Approval Phase afișează în ce fază de aprobare este schimbarea. Fila Approvers afișează următoarele informații importante:

■ Starea de aprobare

■ Semnăturile grupurilor și persoanele care trebuie să aprobe cererea de schimbare

■ Factori alternativi de aprobare

Aprobările pot fi generate automat, pe baza informațiilor captate în cererea de schimbare. Acestea pot fi si generate manual în cazuri speciale.

Formularul de schimbare – fila Approvers

Dacă este necesar, administratorul aplicației poate configura fluxul de aprobare

a cererilor de schimbare conform cu modelul de afaceri al organizației dvs. Aceasta determină ce

cereri de schimbare necesită aprobare și prin ce tip de proces de aprobare trec acestea.

Managementul versiunilor este de asemenea instalat cu procese implicite de aprobare out-of-the-box pentru utilizare globală.

Multipli factori de aprobare și multiple niveluri de aprobare

Poate exista mai mult de un nivel de aprobare și pot fi mai mulți factori de aprobare pe fiecare nivel. Cel puțin un factor de aprobare pe fiecare nivel trebuie să aprobe cererea de schimbare înainte de a fi revizuită de următorul nivel de aprobare. Factorii de aprobare pot revizui acțiunile factorilor anteriori prin vizualizarea comentariilor acestora și șirului de audit.

Puteți configura procesul de aprobare ca unul sau toți factorii de aprobare pe fiecare

nivel de aprobe cererea de schimbare înainte ca aceasta să fie revizuită de următorul nivel

de factori de aprobare. Modificați setarea If Multiple Approvers pentru configurarea acestei opțiuni.

Administratorul aplicației are și posibilitatea de a configura procesul de aprobare (parent-child) al lanțului de management al schimbărilor. Dacă o schimbare este configurată pentru procesul de aprobare din lanțul de management, managerul solicitantului este notificat.

Dacă schimbarea este aprobată de toți factorii de aprobare, procesul de aprobare este complet și schimbarea trece la următoarea stare. Dacă schimbarea este respinsă de orice factor de aprobare, aceasta este oprită. Managerul schimbării sau coordonatorul poate anula ulterior schimbarea sau o poate actualiza și redepune spre aprobare. Aprobarea cererii de schimbare poate finaliza aprobarea sau declanșa următorul pas din procesul de aprobare. Dacă există mai multe niveluri de factori de aprobare, aprobarea dvs. poate trimite cererea de aprobare la următorul factor de aprobare sau dacă respingeți cererea, procesul de aprobare este finalizat, indiferent dacă sunt definiți mai mulți factori de aprobare. Semnătura de aprobare nu poate fi modificată după ce cererea a fost respinsă, iar procesul de aprobare este finalizat. Dacă cererea de schimbare va fi implementată, managerul schimbării trebuie ca mai întâi să repornească procesul de aprobare.

BMC Remedy Service Desk

BMC Remedy Service Desk acționează ca singur punct de contact pentru cererile utilizatorilor, incidentele depuse de utilizatori și incidentele generate de infrastructură. O organizație trebuie să adreseze zilnic incidentele imediate pentru a-și întreprinde activitatea. Aceste incidente imediate sunt punctul central al procesului de management al incidentelor. În plus, este esențial să se detecteze, analizeze și rezolve problemele din infrastructură.

BMC Remedy Service Desk constă din două aplicații:

■ BMC Remedy Incident Management – managementul incidentelor

■ BMC Remedy Problem Management – managementul problemelor

Aceste aplicații conforme ITIL automatizează procesele de management al incidentelor și al problemelor pentru a permite echipei IT să răspundă eficient și rapid la condiții care interferează cu serviciile critice.

Procesul de management al incidentelor se concentrează pe restabilirea utilizatorilor după întreruperi.

Procesul de management al problemelor se concentrează pe determinarea cauzei de bază a unei probleme și pe folosirea procesului de management al schimbărilor pentru corectarea acestei cauze.

Relația dintre procesele de management al incidentelor, problemelor și schimbărilor

2.2. „BMC Remedy Incident Management”

Misiunea procesului de management al incidentelor este să rezolve cererile de incidente cât mai rapid posibil într-un mod prioritizat. Modulul de management al incidentelor BMC Remedy Incident Management este conceput să sprijine în realizarea acestui scop. La tratarea cererilor de incident, BMC Remedy Incident Management este inițiat tipic la un apel de client, o cerere de servicii sau un eveniment automat. Un exemplu de eveniment automat poate fi alerta sistemului de monitorizare, precum BMC Service Impact Manager (BMC SIM). Principalul obiectiv al procesului de management al incidentelor, conform cu standardele ITIL, este să „restaureze serviciul normal cât mai rapid posibil cu o minimă întrerupere a activității, astfel asigurând menținerea celor mai bune niveluri realizabile de disponibilitate și serviciu”.

La tratarea cererilor de incident, următoarele bune practici sunt critice pentru succes:

■ Prioritizare, astfel încât incidentele care cauzează organizației cele mai multe probleme, precum pierderi din vânzări sau oprirea lucrului, să fie remediate primele. Această abordare vă conservă resursele și le folosește acolo unde sunt cel mai necesare.

■ Înregistrarea consistentă a detaliilor cererii de incident. Aceste detalii sunt apoi puse la dispoziția altor aplicații, precum BMC Remedy Change Management. Aceasta înseamnă că intrările pot fi căutate, analizate și comunicate prin toată organizația.

■ Integrare cu BMC Atrium Configuration Management Database (BMC Atrium CMDB). Aceste informații pot fi folosite atât pentru rezolvarea incidentelor imediate cât și pentru a stabili dacă și alte sisteme pot fi afectate.

Procesul de management al incidentelor gestionează și cereri de servicii de la clienți, precum „Am nevoie de un nou laptop” sau „Am nevoie de acces la această resursă de rețea”. Clienții pot folosi BMC Service Request Management pentru a introduce cereri de servicii. Dacă BMC Service Request Management nu este disponibil, organizația dvs. poate folosi BMC Remedy Incident Management.

Înregistrarea cererilor de servicii

Când un utilizator contactează centrul de asistență cu o cerere de incident, mai întâi determinați natura cererii. Dacă cererea este cu privire la o cerere înregistrată anterior, interogați cererea și actualizați utilizatorul cu starea curentă. Dacă cererea privește un incident ce a fost rezolvat, dar pentru care soluția nu a fost eficientă, redeschideți înregistrarea cererii de incident și atribuiți incidentul la un specialist.

Dacă aceasta este o cerere nouă ce incident, creați o nouă înregistrare de cerere de incident prin captarea informațiilor cheie despre utilizator și incident. Dacă este posibil, soluționați incidentul imediat și apoi finalizați cererea de incident, în caz contrar vă asigurați că cererea de incident este atribuită grupului corespunzător. Următoarea figură furnizează un plan general al procesului de înregistrare a

cererilor de incident, descris de SMPM.

Înregistrarea cererilor de incident

2.3. „BMC Remedy Problem Management”

Misiunea procesului de management al problemelor este să minimalizeze numărul incidentelor. Modulul BMC Remedy Problem Management sprijină acest obiectiv prin gestionarea investigațiilor, erorilor cunoscute și intrărilor în baza de date cu soluții. Managementul problemelor poate preveni în mod activ apariția incidentelor, erorilor și problemelor suplimentare.

Investigarea problemelor

Un important obiectiv ITIL este investigarea și rezolvarea problemelor într-un

efort continuu de tăiere a costurilor și îmbunătățire a serviciilor. Investigarea unei probleme ajută o organizație IT să determine cauza de bază a incidentelor. Aceasta inițiază acțiuni care să ajute la îmbunătățirea sau corectarea situației, prevenind reapariția incidentului. De exemplu, dacă computerele rămân fără spațiu pe disc, în mod ideal problema poate fi rezolvată înainte de a deveni un incident.

Investigațiile sunt declanșate de obicei printr-o analiză a incidentului sau printr-o aplicație precum BMC Event Manager. BMC Event Manager poate genera un eveniment la apropierea de un prag de capacitate. Aceasta poate determina coordonatorul problemei să creeze o investigație a problemei pentru a preveni întreruperile cauzate de lipsa de capacitate.

După ce investigarea problemei prezintă cauza, aceste informații pot rezulta în:

■ O eroare cunoscută, care descrie atât cauza de bază cât și soluția structurală propusă pentru eliminarea cauzei de bază

■ O intrare de soluție care descrie modul de abordare a problemei

Procesul de revizuire a cererii de incident

Revizuirea cererii de incident este primul proces din ciclul de management al problemelor. Efectuați analize ale cererilor de incident periodic, conform cu programul organizației. La efectuarea unei analize a cererii de incident, analizați informațiile cererii de incident pentru a identifica potențiale probleme din servicii pentru care sunteți responsabil. Aceste informații sunt cel mai adesea obținute din aplicația BMC Remedy Incident Management. Cu toate acestea, informațiile despre incident pot veni și de la specialiști care au rezolvat cereri de incident cu o metodă și care consideră că incidentul poate reapărea dacă cauza de bază nu este eliminară rapid. După ce identificați o problemă, creați o nouă investigație de problemă. Corelați investigația problemei cu cererile de incident ce au fost cauzate de problemă. De asemenea, puteți crea o investigație dintr-o cerere de incident în Incident.

Crearea unei investigații dintr-o cerere de incident creează automat o relație între cererea de incident și problema nou-creată. Apoi atribuiți noua investigație la un specialist pentru analiză. La atribuirea investigației, alegeți un specialist care are competențele, disponibilitatea și drepturile de acces necesare pentru efectuarea analizei. Dacă găsiți o cerere de incident în timpul analizei pentru care a fost deja înregistrată o investigație, trebuie să corelați cererea de incident cu investigația.

Revizuirea cererii de incident

Analiza cauzei de bază

După ce investigația problemei este atribuită la dvs. pentru investigare, efectuați o analiză a cauzei de bază pentru a determina cauza problemei. Dacă problema a cauzat unul sau mai multe incidente, mai întâi încercați să găsiți o soluție temporară pentru restaurarea serviciului cât mai rapid posibil. Dacă este disponibilă o soluție temporară, actualizați înregistrarea investigației cu detalii despre soluție, inclusiv modul de implementare. Aceste informații pot fi folosite ulterior pentru a rezolva alte incidente cauzate de aceleași probleme sau probleme similare până când este găsită și implementată o soluție structurală.

După evaluarea soluțiilor temporare, începeți să investigați cauza de bază a problemei. După găsirea cauzei de bază, actualizați investigația cu o descriere a cauzei de bază.

După determinarea cauzei, investigați posibile soluții structurale. Asigurați-vă că adăugați o descriere a fiecărei opțiuni la investigația problemei alături de o recomandare pentru soluția preferată.

Dacă puteți aplica o soluție structurală, implementați soluția și apoi actualizați investigația problemei cu aceasta. Dacă procesul de management al schimbării este necesar pentru soluționarea sau rezolvarea permanentă a cauzei de bază, trebuie să informați coordonatorul problemei că managementul schimbărilor trebuie implementat în analiză.

Dacă nu puteți determina cauza de bază a problemei sau nu puteți propune o soluție structurală, atunci înregistrați asta în investigația problemei alături de o explicație.

Când terminați analiza cauzei de bază, indiferent de rezultat, trebuie să informați coordonatorul problemei asupra faptului că sarcina dvs. a fost îndeplinită.

Analiza cauzei de bază

Închiderea investigației

Când sunteți notificat de specialist că problema este rezolvată, verificați acest fapt. După ce ați verificat rezolvarea, închideți problema în investigație și orice erori cunoscute asociate. Dacă schimbarea a fost propusă dar nu a fost implementată sau dacă schimbarea nu a rezolvat problema, stabiliți dacă există o soluție diferită pentru problemă. Dacă există, atunci puteți atribui investigația problemei înapoi specialistului pentru analize suplimentare sau o puteți reatribui la un alt specialist.

Dacă investigația și analiza detaliată arată că nu există actualmente mijloace practice de rezolvare sau abordare a cauzei de bază a problemei, actualizați investigația pentru indicarea unui impas. După aceea, trebuie să reatribuiți periodic investigația problemei pentru a determina dacă o nouă tehnologie sau dacă o abordare diferită la cauza de bază a problemei poate furniza o soluție structurală.

Închiderea problemei

2.4. Erori cunoscute

O eroare cunoscută este o problemă care a fost diagnosticată cu succes și pentru care a fost propusă o soluție permanentă. După analiza cauzei de bază și propunerea unei soluții structurale, este creată o eroare cunoscută pentru solicitarea implementării soluției propuse. Implementarea soluției propuse face parte din procesul de management al schimbării. Procesul erorii cunoscute poate avea unul dintre următoarele rezultate:

■ O cerere de schimbare pentru implementarea soluției necesare

■ Închiderea erorii cunoscute ca problemă acceptată, cu actualizări la baza de cunoștințe ce conține măsuri de evitare a problemei

Baza de date cu soluții

Baza de date cu soluții este un simplu depozit cu potențiale soluții sau abordări la probleme de infrastructură. O intrare în baza de date cu soluții conține informații ce pot fi necesare pentru furnizarea sau restaurarea unui serviciu.

Datele din baza de date cu soluții devin aport la un sistem complet de management al cunoștințelor cu folosirea aplicației BMC Remedy Knowledge Management.

2.5. Instrucțiuni ITSM

Arhitectură:

Comenzi utile pe nivelurile medii:

/opt/apache/tomcat/bin ./shutdown.sh 2x

/opt/apache/tomcat/bin ./startup.sh

Vizualizare procese:

ps -ef | grep tomcat

root 17960 1 1 Jan23 ? 08:03:57 /usr/lib/jvm/jre-1.7.0-openjdk.x86_64/bin/java -Djava.util.logging.config.file=/opt/apache/tomcat/conf/logging.properties -Xms1024m -Xmx2048m -XX:MaxPermSize=256m -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/opt/apache/tomcat/endorsed -classpath :/opt/apache/tomcat/bin/bootstrap.jar -Dcatalina.base=/opt/apache/tomcat -Dcatalina.home=/opt/apache/tomcat -Djava.io.tmpdir=/opt/apache/tomcat/temp org.apache.catalina.startup.Bootstrap start

Comenzi SSH utile:

restartare ITSM: /opt/bmc/ARSystem/bin ./arsystem stop

./arsystem start

restartare servet Email : /opt/bmc/ARSystem/AREmail ./emaild.sh stop

will be restarted automatically by armonitor process

Capitolul III: Proiectarea bazelor de date

3.1. Procesul de proiectare logica al bazei de date

Succesul unui mediu de baze de date este puternic determinat de cat de bine a fost structurat logic baza de date. Acest capitol introduce concepte de baza in proiectarea bazelor de date.

Ciclul de viata. Durata de viata (lifecycles)

Sintagma „ciclu de viata” este folosita ca loc comun in analiza sistemelor si in prelucrarea datelor pentru o secvența de faze in evoluția software-ului. Concepte de „ciclu de viata” sunt folosite pentru a explica dezvoltarea sistemelor, pentru a organiza proiecte de sisteme, pentru a standardiza documentația si pentru a comunica progresul sistemelor.

In general, nu exista concordanta asupra ceea ce înseamnă faza in ciclul de viata al sistemului. Unii vorbesc de 17 faze pentru a descrie dezvoltarea sistemului, alții nu folosesc mai mult de trei faze. Multe propuneri cad pe undeva intre aceste limite.

Următoarele faze descriu percepția tipica a procesului de dezvoltare a sistemului:

Definirea problemei: recunoașterea faptului ca este nevoie de un sistem nou, identificarea scopurilor si a obiectivelor, redactarea (întocmirea) costurilor si a restricțiilor de livrare.

Studiul de fezabilitate decizia asupra magnitudinii efortului de dezvoltare,urmărirea disponibilității resurselor, estimarea costurilor si planificării preliminare, evaluarea costurilor versus beneficii.

Analiza sistemului existent: revederea documentației de sistem, a soft-ului si a procedurilor existente si identificarea deficientelor si insuficientelor sistemelor existente.

Proiectarea preliminară: identificarea subsistemelor majore, a funcțiilor lor, a interfețelor subsisteme, descrierea fișierelor de baza si a fluxului in sistem, analizarea mediilor de calculator gazda si de comunicații precum si a formelor de baza pentru intrări si ieșiri.

Proiectarea detaliata: identificarea modulelor de codificat, dezvoltarea algoritmilor detaliați, a procedurilor , a fișierelor, a organizării rapoartelor si a formelor de intrare.

Programarea: scrierea codului pentru a implementa modulele identificate in faza de proiectare detaliata si testarea unităților.

Testarea : dezvoltarea datelor de test pentru integrarea sistemului, testarea sistemului, evaluarea performantei sistemului si obținerea acceptării pentru sistem.

Conversia: transferarea sistemului in starea de producție; convertirea fișierelor in noile formate, conducerea operațiilor paralele si realizarea despărțirii de cel vechi.

Operarea: gestionarea sistemului, colectarea de rapoarte de probleme, oferirea de rapoarte si de date operaționale , proiecția încărcărilor de lucru.

Figura. 3.1 Durata de viata convenționala pentru dezvoltarea de sisteme:

Aceasta este o vedere tradiționala a dezvoltării sistemelor, care statuează dezvoltarea sistemelor pe instrucțiuni precise de cerințe funcționale si apoi o prelucrează de la proiectarea preliminară la cea detaliata pana când sistemul terminat este livrat utilizatorilor săi. Ea presupune ca sistemele se nasc, trăiesc si apoi, eventual, se îmbolnăvesc si mor, după care sunt înlocuite cu mai „tinere” si imbunatatite generări de cod. Ciclul de viata al codului aplicațiilor sistem este de aproximativ 10 ani, dar in scădere. Datele, ca si sistemele au ciclu de viata. Când datele se nasc, ele sunt personale, căci sunt proprietatea persoanei care le-a creat si sunt complet sub controlul persoanei. Daca datele persoanei se dovedesc utile, exista opresiune care le face cunoscute din ce in ce mai multor persoane, așa ca datele personale devin date partajate. Datele nu mor niciodată. Datele istorice pot fi arhivate, dar ele nu dispar. Ele nu sunt înlocuite de date noi, cu toate ca pot primi roluri diferite atunci când noi date sunt achiziționate. Noile sisteme de aplicații nu sunt create pentru a înlocui date vechi cu date noi ci pentru a imbunatati modul de prelucrare si gestionare a datelor. Atunci când datele sunt partajate, calitatea lor trebuie sa fie mai bine controlata. Cu cat o data se maturizează, nevoia de control creste. Cu cat oamenii se încred mai mult in data, cu atât devine mai important ca datele sa fie protejate, accesibile si de o înalta calitate. Recunoașterea unui ciclu de viata a datelor conduce la intelegerea faptului ca datele au vieți distincte de cele ale sistemului construit pentru a le manipula si accesa.

3.2. Necesitatea unei metodologii de dezvoltare a sistemelor axate pe date

Daca bazele de date sunt implementate folosind orientarea tradiționala pe aplicații , atunci proiectele de baze de date vor urma ciclul de viata tradițional. Din nou, acest ciclu presupune ca bazele de date vor muri si lucrul acesta este pregătit inca din start.

O alternativa este de a lăsa resursa de date sa evolueze, fara a o constrânge la limitele da astăzi ale aplicațiilor si organizațiilor. Intr-adevăr anumite companii muta oamenii pentru a imbunatati comunicarea in cadrul organizației si intelegerea de către angajați a afacerii companiei. Marginile naturale ale aplicației au tendința de a mișca mai încet decât cele ale organizației, dar totuși ele se mișca.

O modalitate de a implementa un mediu efectiv orientat predate este de adopta un cadru care:

explica tipurile de relații de date pertinente in mediile de baze de date;

accentuează independenta aspectelor utilizator si implementare in gestionarea datelor;

este independent de orice abordare de modelare date particulara unui vânzător de DBMS.

Un astfel de cadru este abordarea cu trei scheme . O definiție de dicționar a schemei este „diagrama, plan, proiect, schita”. Intr-un context de gestionare de date, cuvântul schema înseamnă insa o structura de date care este formalizata in concordanta cu o mulțime de reguli. O schema este un model, pictat uzual in diagrame si câteodată insotit de descrieri in cuvinte. Abordarea cu trei scheme are trei tipuri de scheme, fiecare cu un scop specific. In plus, abordările alternative pot fi mapate pe abordarea cu trei scheme.

3.3. Abordarea cu trei scheme

Abordarea cu trei scheme se bazează pe presupunerile ca:

calculatoarele si utilizatorii au nevoie de a vedea aceleași date in moduri diferite;

diferiți utilizatori au nevoie de a vedea diferite parți ale ansamblului de date;

este de dorit pentru calculatoare si utilizatori sa fie posibil a schimba modul in care vad ei datele;

nu este de dorit ca un calculator sa dicteze sau sa restrângă modurile in care utilizatorii vad datele;

Astfel, este necesar sa fim in stare sa oferim diferitele vederi ale resursei de date.

Separarea vederilor utilizator de vederile de implementare. Utilizatorii au nevoie sa lucreze cu reprezentări de date care sunt independente de modurile in care datele sunt memorate si gestionate in calculator. Utilizatorul vede datele ca entitati la nivel înalt, de exemplu instrumente, vehicule, clienți. Deocamdată, facilitatile calculatorului sunt in stare sa lucreze cu reprezentări fizice. Ele vad datele in termeni de înregistrări si fișiere, cu structuri index, B-arbori, liste inlantuite, pointeri, adrese, pagini, etc. In concluzie, exista doua tipuri diferite de vederi asupra datelor, vederi utilizator si vederi implementare. Vederile utilizator sunt modelele lumii reale; ele comunica cu utilizatorii. Vederile de implementare, pe de alta parte, sunt orientate spre calculator.

Folosind terminologie abordării cu trei scheme, scheme externe sunt vederi utilizator asupra datelor așa cum sunt văzute de una sau mai multe aplicații , iar schemele interne sunt vederi de implementare ale bazelor de date. Schemele conțin metadate, adică date despre date. Metadatele dau semnificații ; valorile de date dau fapte; semnificațiile si faptele dau împreuna datele.

Mapări interscheme. Obiectivul gestionarii datelor este de a permite utilizatorilor sa acceadă date computerizate. Astfel, trebuie sa existe mapări sau transformări intre vederile utilizator si vederile de implementare. Aceste mapări ar putea fi simple daca exista numai o schema externa si numai o schema interna. Exista o multitudine de scheme externe, dar si numărul schemelor interne in întreprindere poate fi mai mare. Fiecare schema externa poate fi mapata direct pe baza de date. Aceasta soluție suferă, totuși, atunci când oricare din tipurile de schema se modifică. De exemplu, dacă o bază de date fizică este restructurată pe disc pentru a oferi o performantă mai mare, atunci maparea pe fiecare schemă externă care referă baza de date poate fi afectată. Dacă o schemă externă este revizuită pentru a prezenta datele intr-o manieră oarecum diferită, atunci maparea pe fiecare din bazele de date poate fi afectată. Folosirea mapării directe schema internă – schema externă previne independenta intre aplicații si implementare. Factorii de calculator fizic restricționează astfel modurile in care utilizatorii văd datele lor. Pentru a permite diferiților utilizatori să-și partajeze resursa de date care poate fi implementată pe mai multe baze de date fizice, abordarea cu trei scheme inserează o vedere neutră, integrată intre schemele externe si cele interne. In termenii abordării cu trei scheme, aceasta vedere este schema conceptuală sau vederea intreprinderii sau vederea comunității.

Figura. 3.2. Maparea directă a vederilor utilizator pe vederile de implementare

Figura 3.3 Arhitectura cu trei scheme: O schemă conceptuală oferită pentru integrarea si independența multitudinii de scheme externe și interne

Schema conceptuala. O schema conceptuală este extensibilă, consistentă, accesibilă si partajabilă si ea permite ca resursa de date să evolueze după cum se modică și se maturizează nevoile. Figura 3.3 ilustrează relațiile intre cele trei tipuri de scheme. Schemele si mapările între ele permit atât independența datelor cât și suportul pentru vederi multiple. O schemă internă poate fi modificată pentru a îmbunătății performanța și pentru a profita de noile dezvoltări tehnice, fara a altera schema conceptuala sau schemele externe .Schemele externe pot fi modificate pentru a reflecta schimbări in vederea unei aplicații sau folosirea datelor , fara a afecta schema conceptuala sau schemele interne. Schema conceptuala reprezintă cunostinte pentru date partajabile. Pot exista controale de acces si restricții de securitate asupra acestor date comune, dar ele nu sunt restricționate la a fi cunoscute numai de un utilizator. Schema conceptuala nu descrie date personale ci, mai degrabă, date partajate controlate de întreprindere. Domeniul schemei conceptuale se expandeaza in timp. Abordarea bazata pe date a proiectelor baze de date expandeaza continuu schema conceptuala pentru a include cunostinte despre tot mai multe date partajate. Un proiect baza de date in abordarea bazata pe date nu redefineste resursa de date si nici nu creează o noua baza de date de sine stătătoare. In loc de acestea, fiecare proiect trebuie sa determine modul in care datele din domeniul sau se leagă de ceea ce este deja cunoscut din schema conceptuala. Rezultatul este o resursa de date al cărui domeniu este expandat gradat. Resursele de date ale unei organizații nu pot fi integrate toate deodată, sarcina trebuie executata pe bucati, iar schema conceptuala este interogatorul.

3.4. Ciclul de viata al unui proiect bazat pe date (data-driver)

Obiectivul primar al ciclului de viata al unui proiect bazat pe date este de a implementa bazele de date si software-ul utilizator pe baza unei scheme conceptuale integrate.

Modelul de mai jos nu este singurul ciclu de viata posibil pentru un proiect bazat pe date, dar este unul care a fost testat si s-a arata de succes intr-o varietate de medii. Ciclul de viata al proiectului bazat pe date nu este același cu cel convențional pentru dezvoltarea sistemelor. Abordarea convenționala construiește baze de date si fișiere separate, pe când abordarea bazata pe date construiește baze de date integrate. Abordarea convenționala se bizuie pe declarații complete si corecte de cerințe înainte de a oferi ceva concret utilizatorului. Abordarea bazata pe date promovează prototiparea pentru a ajuta la descoperiră de cerințe, iar utilizatorii contribuie activ si esențial in acest proces de prototipare. Prototipurile oferă posibilitati de cost relativ scăzut pentru a determina care ar trebui sa fie funcția sistemului obiectiv, căci ele permit experimentarea înainte ca proiectarea sa fie realizata in forma finala.

Fazele. Fazele dintr-un proiect de date sunt:

– Examinarea: a stabili domeniul si planificarea proiectului, a colecta si analiza informații despre datele din domeniul proiectului, a dezvolta modele de date logice de nivel înalt, a idenifica posibilitati de imbunatatire.

– Proiectarea: a dezvolta modele de date logice detaliate pentru noul mediu, a planifica procesul de prototipare, a redacta schita cu specificațiile tranzacțiilor bazei de date.

Prototipare: a proiecta structura bazei de date fizice pentru prototipul inițial al bazei de date, a încarcă prototipul, a folosi prototipul pentru a rafina si valida vederile utilizator si a defini tranzacțiile cerute, a dezvolta tranzacțiile si a transfera prototipul in starea de lucru.

Integrare: a integra modele de date prototip cu schema conceptuala si a ajusta mapările interscheme.

Reglaj: a rafina structurile bazei de date fizice si a optimiza software-ul.

Revizie: a monitoriza calitatea ieșirilor proiectului si a transfera prototipul din starea de pregătire in starea de producție.

Aceasta abordare a proiectării se bazează puternic pe construcția modelelor de date care reprezintă resursele de date di diferite perspective. Accentul, in fazele de examinare, proiectare, prototipare si integrare cade pe modelele de date logice, care reprezintă semnificația datelor.

Prototiparea bazei de date. Sa notam buclele de feedback din ciclul de viata din figura 3.4. Buclele de feedback din faza de prototipare permit modificare vederilor utilizator si a acestor contribuții la schema conceptuala înainte de a muta baza de date in starea de producție. Utilizatorii sunt puternic implicați in faza de prototipare, înainte ca baza de date sa devină o declarație completa de cerințe. Acesta este in contrast cu ciclul de viata al dezvoltării sistemelor convenționale, care asteapta pana când toate cerințele

sunt cunoscute si abia apoi începe proiectarea. Folosind acest ciclu de viata al proiectului, se pot construi prototipuri si se pot pune in lucru rapid, de ordinul zilelor. Ciclul de viata lucreza, de asemenea, cu prototipuri de domeniul larg, in care trebuiesc luni de zile pentru a ajunge in stadiul de inițiere al proiectului la o baza de date in lucru. Structura fizica prototip a bazei de date poate fi modificata astfel incat ea sa acopere mai eficient performantele de producție cerute. Modelul sau de date logice, totuși, nu este abandonat ci este integrat in schema conceptuala si mapat pe structura fizica, adică pe versiunea de producție a schemei interne.

Echipele proiectului. Abordarea bazata pe date in dezvoltarea bazelor de date cere echipe de proiect compuse atât din personal de prelucrare date cat din utilizatori. Decât sa-si trimită cerințele lor departamentului de prelucrare date si apoi sa vadă ce primesc de acolo, utilizatorii (end-users) ajut ala determinarea relațiilor si tranzacțiilor de date. Ei sunt implicați in sistem ca I creatorii si numai după ce acest a fost dezvoltat, ca si indivizi ce trebuiesc sa trăiască cu el.

3.5. Integrarea si schema conceptuala

Una dintre cele mai importante caracteristici ale acestui ciclu de viata al dezvoltării este aceea ca fiecare proiect nu trebuie sa-si recreeze propria sa baza de date separata. Mai degrabă, fiecare proiect trebuie sa examineze cum se leagă datele din domeniul sau cu datele din schema conceptuala existenta. Schema conceptuala evoluează cum apar proiecte adiționale bazate pe date. Fiecare proiect isi poate creea propria baza de date fizica, prototip separata, dar se urmareste integrarea acestor baze de date. Câteodată initiaza un proiect si apoi se descoperă ca datele necesare pentru a-l susține sunt deja disponibile si descrie in schema conceptuala. Se poate dezvolta atunci o noua schema externa si ea se poate mapa pe schema conceptuala care este mapata pe una sau mai multe scheme interne.

Cele de mai sus nu implica crearea unei baze de date uriașa pentru a conține toate informațiile de producție necesare, deoarece in concordanta cu abordarea cu trei scheme, schema conceptuala poate fi mpata pe oricâte scheme interne, fiecare reprezentând o baza de date fizica. Aceste baze de date fizice pot fi rezidente pe mai multe calculatoare si pot fi distribuite geografic pe tot cuprinsul unei intreprinderi. Schema conceptuala integrează aceste concepte distribuite. Astfel, schema conceptuala integrează vederile orientate pe aplicație, reprezentate pe schemele externe, sau dintr-o alta perspectiva, ea integrează vederile orientate pe implementare, reprezentarea de scheme interne.

Figura 3.4 Ciclu de viata al unui proiect bazat pe date, cu prototipuri.

Schema conceptuala externa

Scheme conceptuale pasive si active. Datele nu sunt integrate pana când legătura ermetica dintre schemele interne si externe nu este sparta. Schema conceptuala trebuie sa controleze accesul la manipularea resurselor de date, si nu aplicațiile program. Spargerea legăturii intre schemele interne si externe nu este simpla. Exista doi pași intermediari care superimpun, la început o schema conceptuala pasiva si apoi o vedere completa cu trei scheme in vârful legăturii directe intern – extern . Moștenirea majorității mediilor de aplicații baze de date este arătata in figura 4.5.a schemele interne si externe sunt unite prin codul aplicației program. Nu exista nici o vedere intreprindere a resursei de date. Notația cu “punct mare” folosita in figura 4.5 arata tipul de relație posibila intre entitățile din cutii. Un “punct mare” înseamnă mai multe. Figura 4.5a spune ca o schema interna poate suporta direct mai multe scheme externe si ca o schema externa poate fi suportata direct de mai multe scheme interne.

In pasul 1 (fig. 3.5.) se introduce schema conceptuala, iar schemele interne si externe continua sa fie legate direct. O schema conceptuala descrie toate datele disponibile in toate schemele interne , intr-o vedere integrata, neutra si pasiva a resurselor de date. Orice control pe care il are schema conceptuala asupra resurselor de date depinde complet de politicile, procedurilor si administrarea resurselor. Schema conceptuala rezida intr-un dicționar de date si este scrisa ca un model de date logice.

Pasul 2 arata o schema conceptuala activa. Atunci când se folosește o schema conceptuala activa, software-ul de gestionare date relizeaza operațiile necesare pentru a prelua o cerere utilizator in forma din schema externa si a o mapa pe schema conceptuala si apoi pe cele interne. Aplicațiile program se confrunta numai cu schemele externe. O aplicație program sau o tranzacție particulara poate accesa date din mai multe baze de date, fără a se preocupa de locul unde se găsesc datele. Baza de date poate sa fie distribuita pe mai multe calculatoare ale rețelei. Transformările interscheme nu se realizează in codul aplicației program ci in software-ul de gestionare date care oferă controlul activ al schemei conceptuale. Logica poate fi astfel partajata de mai mulți utilizatori si de mai multe aplicații.

Cu toate ca software-ul de gestionare date care sa realizeze transformările interscheme in medii de date distribuite nu exista inca forma de producție , prototipuri au fost construite de către mai multe proiecte de cercetare. Eforturile depuse in construcția schemelor conceptuale pasive astăzi vor fi răsplătite atât pe distanta scurta cat si pe distanta lunga prin planificarea si implmentarea imbunatățită a sistemelor informatice

Figura. 3.5. Pașii in controlul schemei conceptuale

3.6. Planificarea pentru un mediu baze de date

Probabilitatea de a implementa cu succes un mediu baze de date poate fi mărita daca se urmează sugestiile:

Recunoaște ca un DBMS reprezintă un instrument pentru gestionarea resursei de date si nu o metoda extravaganta de acces la fișiere.

Formează un comitet adecvat de gestionare a resurselor.

Păstrează domeniul fiecărui proiect de implementare rezonabil si realizabil rezultatele vor fi disponibile in sase luni.

Planifică procesul de dezvoltare si stabilește puncte de revizie.

Fazeaza implementarea (si evoluția schemei conceptuale) in incremente realiste de atins cu un plan de fazare conservator.

Deplasează responsabilitățile spre experți si fi sigur ca utilizatorii isi definesc cerințele lor si validează posibilitățile sistemului.

Antrenează o echipă tehnică in tehnologia bazelor de date, devreme și continuu.

Stabilește o funcție de administrare date.

Când este potrivit, folosește prototipuri pentru a defini cerințe.

Cere și accepta ajutor de la un distribuitor de baze de date

Ferște-te de încurcături, inclusiv de supradependența de distribuitorul DBMS.

Planificarea pentru un mediu baze de date înseamnă înțelegerea abordării bazate pe date în gestionarea datelor. O baza de date trebuie proiectată pentru generalitate, flexibilitate si extensibilitate. După ce baza de date a fost proiectată, programele orientate pe aplicații și tranzacții care depind de acea bază de date pot fi specificate. Mai important pentru succesul pe termen lung al proiectului este neutralitatea și calitatea proiectării bazei de date logice decât programarea.

Planificarea pentru un mediu baze de date înseamnă de asemenea recunoaștera faptului ca un DBMS este un instrument pentru acel mediu și nu un obiectiv.

Capitolul IV: „Studiu de caz”- Utilizarea limbajului standard SQL

4.1. Scurt istoric al limbajului SQL

Microsoft SQL Server este un sistem de gestionare de baze de date relaționale (RDBMS), produs de compania americană Microsoft. Microsoft SQL Sever foloseste o varianta de SQL numita Transact-SQL(T-SQL), care este o implementare de SQL-92 cu unele extensii pentru procedurile stocate și tranzacții. Oracle este un sistem de management al bazelor de date relaționale produs și comercializat de către Oracle Corporation. Oracle a dezvoltat limbajul de programare PL/SQL, care este o extensie a limbajului SQL, punând la dispozitia programatorilor un instrument puternic pentru crearea de obiecte în baza de date. Obiectele din baza de date pot fi accesate direct prin interfețe specilizate, dar pot fi accesate și prin intermediul programelor scrise în alte limbaje de programare cum ar fi Java, C++,PHP, etc., folosind funcții standard de conexiune pentru ODBC sau JDBC. Cel mai răspândit tip de baze de date este cel relațional, în care datele sunt stocate în tabele. Pe lânga tabele, o bază de date relațională mai poate conține și alte obiecte cum ar fi vederi, indecși, proceduri și funcții stocate, declanșatori, constrângeri de integritate, etc.

SQL a fost conceput ca un limbaj standard de descriere a datelor și acces la informațiile din bazele de date, ulterior dezvoltându-se ca o adevărată tehnologie dedicată arhitecturilor

client-server. Utilizat inițial de către firma IBM pentru produsul DB2, limbajul de interogare al bazelor de date relaționale SQL a devenit la mijlocul deceniului trecut un standard în domeniu. De atunci și până în prezent au fost dezvoltate un număr de 7 versiuni ale standardului SQL, trei dintre acestea aparținând Institutului Național American de Standarde (ANSI), celelalte fiind concepute de firme de prestigiu ca IBM, Microsoft, Borland, sau de către consorțiile industriale SAG (The SQL Access Group) și X/Open, primul format din sute de firme ce comercializează software pentru baze de date, iar cel din urmă orientat spre activități de promovare a standardelor în domeniul sistemelor deschise. Din păcate, lipsa unui standard unic SQL are drept consecințe creșterea costurilor programelor de gestiune a bazelor de date și îngreunează

întreținerea arhitecturilor client/server.

Termenul SQL reprezintă o prescurtare a Structured Query Language.

Comenzile principale în cazul limbajului SQL se referă la cele cinci operații de bază care se pot efectua într-un limbaj relațional:

• Crearea/ștergerea unei tabele

• Inserarea de noi linii intr-o tabelă

• Ștergerea unor linii dintr-o tabelă

• Modificarea unor linii dintr-o tabelă

• Listarea selectivă a datelor din una sau mai multe tabele

În acest mediu există două moduri pentru crearea interogărilor: modul de scriere efectivă a cererilor în partea de Queries sau un mod grafic mult mai prietenos utilizatorului numit Design View. Vom prezenta interogările și în primul mod: SQL VIEW, dar și în modul grafic.

4.2. Crearea de tabele

Comanda de creare de noi tabele în baza de date curentă în limbajul SQL standard este CREATE TABLE.

Sintaxa simplificată pentru această comandă este următoarea:

CREATE TABLE nume_tabela (

coloana_1 descriere_1,

coloana_2 descriere_2,

……………………….,

coloana_n descriere_n,

[alte_descrieri]

)

unde coloana_x este numele coloanei, iar descriere_x conține tipul valorilor acelei coloane și alte elemente de descriere pentru ea. În descrierea unei coloane se poate specifica, pe lângă tipul valorilor sale și alte constrângeri de integritate ca:

• NOT NULL indică faptul că valorile aferente coloanei respective nu pot avea valori de tip null, care nu înseamnă zero, ci lipsă de informație.

• PRIMARY KEY indică faptul că coloana specificată cu această constrângere va fi cheie primară pentru acest tabel.

• FOREIGN KEY necesită ca fiecare valoare din coloană să existe într-o coloană corespondentă dintr-o tabelă referită.

Constrângerea FOREIGN KEY poate face referire doar la coloane care sunt PRIMARY KEY sau UNIQUE în tabela referită.

• DEFAULT indică o valoare implicită care îl ia un câmp al unei tabele.

Interogările prezentate mai departe vor fi făcute în modul SQL VIEW. Pentru a intra în acest mod ne poziționăm pe obiectul Queries și apăsăm butonul . Va apărea o fereastră pentru alegerea tipului de creare a interogării. Facem opțiunea Design View și vom face opțiunea View – SQL View din noul meniu sau apăsăm clic dreapta de la mouse pe fereastra Query și facem

opțiunea SQL View.

Exemplu:

crearea tabelelor cu structura prezentată la începutul capitolului.

create table Facultate(

CodFac integer primary key,

Denumire text(50),

Adresa text(50),

NumeDecan text(20));

create table StudPersonal(CodStud integer primary key,

CNP integer,

Nume Text(25),

Init text(3).

Prenume text(20),

DataNasterii date,

LocNast text(50),

Tata text(30),

Mama text(30),

Adresa text(50));

create table Studenti(

CodStud integer primary key,

CodFac integer,

An byte,

Grupa text(6),

Media double,

Bursa integer);

create table Materii(

CodMaterie integer primary key,

Denumire text(30),

An byte,

NumeProfesor text(50));

create table Note (

CodNota integer autonumber primary key,

CodStud integer,

CodMaterie integer,

Nota byte,

Data date);

După rularea acestor fraze SQL vor apărea la obiectul Tables cele 5 tabele noi create.

Cea de-a doua metodă de creare a tabelelor, mai exact metoda grafică este și cea mai des folosită de toți utilizatorii.

Pentru a crea o tabelă în modul Design se face opțiunea “Create table in Design View”. Va apărea o fereastră în care trebuie completată denumirea câmpului, tipul de date asociat câmpului

respective și dacă există observații.

Vom exemplifica decât crearea tabelei Facultate. După completarea denumirii câmpurilor în zona Field Name și a tipurilor de date în zona Data Type vom seta cheia primară. Acest lucru se

face poziționându-ne cu cursorul de la mouse pe partea din stânga câmpului corespunzător cheii primare (în cazul nostru CodFac), se apasă clic dreapta și se face opțiunea Primary Key.

Se salvează tabela cu un nume dat de utlizator.

4.3. Salvarea de tabele

O tabelă se salvează cu opțiunea Save din meniul File, sau printr-un clic pe simbolul din bara de instrumente. Va apărea un mesaj pentru confirmarea salvării tabelei.

Aceeași pași trebuie urmați și pentru celelalte tabele.

În final, partea de obiecteTables va arăta astfel:

4.4. Ștergerea tabelelor

Ștergerea unei tabele se face cu comanda DROP TABLE.

Sintaxa acestei comenzi în limbajul SQL standard este: DROP TABLE nume_tabelă

Exemplu:

Ștergerea tabelei Note se face astfel:

drop table Note;

Ștergerea unei tabele în modul grafic se face astfel: ne poziționăm în obiectul Tables, unde sunt afișate toate tabelele din baza de date, apăsăm clic dreapta de la mouse pe tabelul dorit

pentru ștergere și facem opțiunea Delete.

Va apărea un mesaj de confirmare:

Se va apăsa butonul Yes dacă se dorește într-adevăr ștergerea tabelei sau se apasă butonul No dacă se dorește revenirea asupra operației de ștergere

4.5. Modificarea structurii unei tabele

Modificarea structurii unei tabele în limbajul SQL standard se face cu comanda ALTER TABLE. Această comandă este folosită pentru a adăuga coloane la tabele de bază din baza de

date sau pentru a șterge anumite constrângeri.

O nouă coloană adaugată prin această comandă va avea valoarea null în toate înregistrările care existau în tabelă.

Sintaxa acestei comenzi este:

ALTER TABLE nume_tabela

ADD coloana_n descriere_n [DROP constrangere]

Exemplu:

Adăugarea câmpului Ora de tip integer tabelei Note se face astfel:

alter table Note add Ora integer;

Modificarea structurii unei tabele în modul grafic se face astfel: ne poziționăm în obiectul Tables, unde sunt afișate toate tabelele din baza de date, apăsăm clic dreapta de la mouse pe

tabelul dorit pentru modificare și facem opțiunea Design. Va apărea o fereastră cu structura tabelei. Se vor face modificările dorite și apoi se salvează tabelul.

4.6. Inserarea de noi linii într-o tabelă

Comanda INSERT care permite inserarea de noi linii într-o tabelă are următoarea sintaxă simplificată în limbajul SQL standard:

INSERT INTO nume_tabela [(nume_coloana, …)]

VALUES (valoarea_coloana_1, valoare_coloana_2,…)

Această comandă ne permite inserarea manuală de noi înregistrări. Dacă este prezentă lista de coloane (nume_coloana,…) înseamnă că se dau doar valori pentru aceste coloane, pentru

celelalte asignându-se valori de null.

Exemplu:

Introducerea unor înregistrări in tabela Facultate se face astfel:

insert into Facultate values

(1,’Electrotehnica’,’Noul Local’,’’),

(2,’Energetica’,’Noul Local’,’’),

(3,’Automatica’,’Noul Local’,’Dumitru Popescu’),

(4,’Electronica’,’Leu’,’’),

(5,’Aeronave’,’Polizu’,’’),

(6,’Mecanica’,’Noul Local’,’’),

(7,’Transporturi’,’Noul Local’,’’);

După rularea aceste fraze SQL, tabela Facultate va arăta

astfel:

Dacă un câmp de tip integer nu conține nici o valoare se va scrie NULL, iar dacă este de tip text se va lăsa spațiu. Inserarea datelor într-un tabel în modul grafic se face astfel: ne poziționăm în obiectul Tables, unde sunt afișate toate tabelele din baza de date, apăsăm clic dreapta de la mouse pe tabelul în care dorim să introducem date și facem opțiunea Open. Va apărea o fereastră cu datele deja existente în tabelă. Se vor face inserările de date dorite și apoi se salvează tabelul.

4.7. Ștergerea unor linii dintr-o tabelă

Sintaxa simplificată a comenzii SQL în limbajul standard care șterge liniile dintr-o tabelă este următoarea:

DELETE FROM nume_tabela

[WHERE conditie] [LIMIT numar_linii]

Efectul acestei comenzi este de ștergere a liniilor care îndeplinesc condiția din clauza WHERE. LIMIT se folosește pentru a specifica numărul maxim de linii care se pot șterge cu acea

comandă. În cazul în care clauza WHERE lipsește, toate liniile tabelei vor fi eliminate.

Exemplu:

Ștergerea studenților din tabela Studenti care au media mai mică de 7.

delete from Studenti where medie<7;

Înainte:

După rularea acestei interogări se va șterge înregistrarea a- 4-a, aceasta îndeplinind condiția media<7.

Ștergerea datelor dintr-o tabelă în modul grafic se face astfel: ne poziționăm în obiectul Tables, unde sunt afișate toate tabelele din baza de date, apăsăm clic dreapta de la mouse pe

tabelul din care dorim să ștergem anumite date și facem opțiunea Open. Va apărea o fereastră cu datele existente în tabela respectivă. Pentru a șterge o înregistrare ne poziționăm în partea

stângă a înregistrării dorite pentru ștergere, apăsăm clic dreapta al mouse-ului și facem opțiunea Delete Record.

Va apărea un mesaj de confirmare:

Se va apăsa butonul Yes dacă se dorește într-adevăr ștergerea înregistrării respective sau sa apasă butonul No dacă se dorește revenirea asupra operației de ștergere.

4.8. Modificarea unor linii dintr-o tabelă

Sintaxa simplificată a comenzii SQL în limbajul standard care modifică liniile dintr-o tabelă este următoarea:

UPDATE nume_tabela SET colana1=valoare1,

coloana2=valoare2, ….

[WHERE conditie] [LIMIT numar_linii]

Efectul acestei comenzi este de actualizare a toturor liniilor care îndeplinesc condiția din clauza WHERE, sau a tuturor liniilor din tabelă, în cazul în care lipsește această clauză. Noile valor

sunt date de clauza SET.

Exemplu:

1. Modificarea numelui studentului cu CNP=333333, din Cornel în Vasilescu.

update StudPersonal set nume=’Vasilescu’ where CNP=333333;

Tabela StudPers înainte:

Tabela StudPers după:

2. Mărirea tuturor burselor studenților cu 10% update Studenti set bursa=bursa*1,1;

Tabela Studenti înainte:

Tabela Studenti după:

Modificarea datelor dintr-un tabel în modul grafic se face astfel: ne poziționăm în obiectul Tables, unde sunt afișate toate tabelele din baza de date, apăsăm clic dreapta de la mouse pe

tabelul dorit pentru modificare și facem opțiunea Open. Va apărea o fereastră cu datele deja existente în tabelă. Se vor face modificările asupra datelor dorite și apoi se salvează tabelul.

Modificarea datelor dintr-un tabel în modul grafic se face astfel: ne poziționăm în obiectul Tables, unde sunt afișate toate tabelele din baza de date, apăsăm clic dreapta de la mouse pe

tabelul dorit pentru modificare și facem opțiunea Open. Va apărea o fereastră cu datele deja existente în tabelă. Se vor face modificările asupra datelor dorite și apoi se salvează tabelul.

Capitolul V: Prezentarea aplicației

5.1. „Controlul Inventarului”

Aplicația gestionează informațiile tehnice și economice legate de activitatea de stocuri, urmărind toate aspectele specifice acestei activități.

Aplicația poartă denumirea de “Controlul inventarului” și, după cum sugerează și titlul, este destinată firmelor mari și mijlocii pentru ținerea evidenței stocurilor și deci a inventarelor.

Dintre avantajele aplicației se pot enumera următoarele: gestionarea produselor firmei reținând informațiile cele mai importante și sugestive despre produsele cu care se lucrează, cu alte cuvinte produsele se stochează într-un nomenclator de produse; se rețin informații angajații firmei (informații minime, adică nu se includ informațiile contabile, cum ar fi salariu, concediile de odihnă și cele medicale etc.); informații despre furnizori, cum ar fi numele furnizorului, persoana de contact, adresa, numărul de telefon, număr de fax; categorii de produse, fiecare produs trebuie să facă parte dintr-o categorie de produse (de exemplu alimente, detergenți, papetărie, gablonțuri etc.); informații legate de firma curentă, adică cea care utilizează aplicația; informații legate de transportul mărfii, cu ce anume se realizează transportul (numărul autoturism, prin poștă etc.). Aplicația mai prezintă și o serie de rapoarte care cuprind informații legare de produsele achiziționate, raport detaliat pentru produse cu care firma lucrează și rapoarte cu tranzacțiile efectuate.

După cum se poate observa din sumara prezentare aplicația este un mare ajutor pentru orice firmă mică sau mijlocie; acest lucru este accentuat de o interfață accesibilă oricărei categorii de utilizatori. Aplicația prezintă un meniu principal de unde se pot alege una din opțiunile referitoare la vizualizarea sau modificarea informațiilor stocate referitoare la produse, alte informații (adică informațiile legate de angajați, furnizori, categoriile de produse, transport și informațiile firmei utilizator) și vizualizarea sau listarea la imprimantă a rapoartelor. În figura „a” se poate observa fereastra principală a aplicației.

Figura „a”

Aplicația este bazată pe o bază de date care conține toate informațiile necesare stocărilor de informații. Baza de date este alcătuită din șapte tabele, fiecare cu specificul ei. Tabelele cele mai simple ale bazei de date sunt cele care reține informațiile legate de categoriile de produse cu care firma lucrează și tabela în care se reține informațiile legate de efectuarea transportului.

Tabela care stochează informațiile legate de categoriile produselor se numește tblCategori și conține două câmpuri: ID_categorie și strDenumire. Cheia primară a acestei tabele este reprezentată prin câmpul ID_categorie, câmp de tip AutoNumber și care are proprietatea New Values setată pe Increment, adică pentru fiecare nouă înregistrare acest câmp se autocompletează cu valoarea ultimei înregistrări la care se adaugă 1 (se inclementează valoarea precedentă). Aceste proprietăți au fost setate în modul de vizualizare Datasheet View și se pot observa în figura „b”, figură care reprezintă tabela de categori în modul de vizualizare Datasheet View. Câmpul ID_categorie nu acceptă valori duplicate, deoarece este cheie primară, acest fapt se poate observa tot în figura „b” în dreptul proprietății Indexed, deci această tabelă este indexată după câmpul ID_Categorie.

Figura „b”

Tabela care conține categoriile de produse se numește tblTransport și prezintă două câmpuri: ID_transport și strDenumire. Ca în tabela prezentată mai sus, tblCategori, câmpul care păstrează ID-ul este de tip AutoNumber și care are proprietatea New Values setată pe Increment, adică pentru fiecare nouă înregistrare acest câmp se autocompletează cu valoarea ultimei înregistrări la care se adaugă 1 (se inclementează valoarea precedentă) și nu acceptă valori duplicate, deoarece este cheie primară, deci acest câmp este indexat.

Tabela care conține informații legate de angajați se numește tblAngajati și are următoarele câmpuri în componență: ID_Angajat, strNume, strPrenume, strFunctie, strDepartament și strTelefon. Cheia primară a acestei tabele este dată de câmpul ID_Angajat, câmp de tip AutoNumber și care are proprietatea New Values setată pe Increment. Structura tabelei se poate observa mai bine în figura „c”, unde este reprezentată tabela tblAngajati în modul de vizualizare Datasheet View.

Figura „c”

O altă tabelă este cea care stochează informațiile referitoare la produse, acestea sunt următoarele: ProductID (cheia primară a tabelei), ProductName, ProductDescription, CategoryID, SerialNumber, UnitPrice, ReorderLevel și LeadTime.

Este de subliniat faptul că deși câmpul CategoryID este de tip numeric dacă ne uităm în tabelă, sau dacă introducem date legate de produse în acest câmp vom vedea, respectiv vom putea alege, informații legate de categoria produselor, dar nu vom vedea ID-ul, ci denumirea categoriei asociată CategoryID-ului respectiv. Acest lucru este posibil cu ajutorul unor proprietăți înrudite Display Control, Row Source Type și Row Source. Cu ajutorul proprietății Display Control specificăm de unde se ia informația; în cazul tabelei noastre dintr-un Combo Box; proprietatea Row Source Type ne permite să specificăm sursa de unde se iau informații, adică din Table/Query (din tabelă sau query), iar în Row Source specificăm tabela sau query-ul sursă. În exemplul nostru, cu tabela tblCategori, sursa este un query și anume:

SELECT DISTINCTROW [tblCategori].* FROM [tblCategori] ORDER BY [tblCategori].[strDenumire];

Acest query „se uită” în tabela tblCategori și pentru ID-ul de categorie selectat completează în loc denumirea categoriei.

O altă tabelă este cea care reține informațiile degate de firma utilizatoare. Pentru fiecare informație care se dorește stocată există un câmp care reține această informație, și anume există un câmp pentru numele firmei, unul pentru adresă, altul pentru oraș, județ, codul județului, țara, numărul de telefon, numărul de fax și un ID de firmă.

Informațiile legate de furnizori se rețin într-o altă tabelă care prezintă câmpuri pentru fiecare tip de informație ce se păstrează pentru fiecare furnizor (numele furnizorului, persoana de contact, titlul persoanei de contact, adresa furnizorului, orașul, județ, cod poștal, țară, număr de telefon, număr de fax și se pot reține și câteva notițe legate de fiecare furnizor în parte).

Cam acestea ar fi în mare tabelele care păstrează informațiile care se doresc stocate de către firma utilizator. Mai există încă o tabelă care nu poate fi modificată prin intermediul aplicației și utilizatori nici nu cunosc existența ei. Această tabelă se numește Switchboard Items și conține informații legate de meniu.

În momentul în care utilizatorul alege una din opțiunile care se pot vizualiza în figura „a”, cu excepția ultime, cea de ieșire, nu se deschide altă formă, ci în interiorul aceleiași forme se schimbă meniul. Pentru a înțelege mai bine cum funcționează această schimbate de meniu, în figura „d” este prezentat conținutul tabelei Switchboard Items.

Acesta este un avantaj, deoarece dacă se dorește modificarea aplicației, și anume se dorește introducerea unor noi opțiuni, aceste modificări se pot foarte ușor include în aplicație fără a modifica formele, ci doar prin adăugarea noilor opțiuni în tabela Switchboard Items.

Figura „d”

Dar doar această tabelă nu este suficientă pentru a se realiza modificarea meniului; pentru realizarea acestei modificări de meniu din interiorul formei s-a folosit cod de Visual Basic. Pentru a minimiza fereastra principală s-a scris următorul cod Visual Basic:

' Minimize the database window.

DoCmd.SelectObject acForm, "Switchboard", True

DoCmd.Minimize

DoCmd.Hourglass False

Set dbs = CurrentDb()

Set rst = dbs.OpenRecordset("My Company Information")

If rst.RecordCount = 0 Then

rst.AddNew

rst![Address] = Null

rst.Update

MsgBox "Before using this application, you need to enter your company name, address and related information."

DoCmd.OpenForm "My Company Information", , , , , acDialog

End If

rst.Close

dbs.Close

Procedura care face update-ul la schimbarea meniului se numește Form_Current și face refrash-ul pentru lista opțiunilor din noul meniu.

Private Sub Form_Current()

' Update the caption and fill in the list of options.

Me.Caption = Nz(Me![ItemText], "")

FillOptions

End Sub

O cheie străină este o submulțime de atribute (câmpuri) ale tabelei astfel încât valoarea acesteia (a tuturor câmpurilor care o compun) este egală cu valoarea unei chei candidate din tabelul referențiat, sau are valoarea null. O tabelă poate să aibe zero sau oricât de multe chei străine. Câmpurile corespondente din cheia străină și cheia candidată referențiată trebuie să fie compatibile ca tip, dar nu este neapărat nevoie să aibă aceeași denumire. Prin intermediul cheilor se pot defini toate tipurile de asocieri între tabele.

Asocierea 1:1 se realizează între două tabele dacă cheia primară dintr-o tabelă este, de asemenea, cheie primară și în cealaltă tabelă.

Asocierea 1:N se realizează prin intermediul unei chei străine: o cheie străină (definită într-o tabelă) care referențiază o cheie primară dintr-o altă tabelă, realizează asocierea 1:N între tabela care conține cheie primară și tabela care conține cheia străină.

Asocierea M:N nu se poate defini direct între două (sau mai multe) tabele, ci numai prin intermediul unei alte tabele (numită tabelă de asocieri), definită astfel încât fiecare din tabelele date realizează o asociere de tipul 1:N cu tabela de asociere. Pentru aceasta, tabela de asociere conține o cheie străină care referențiază cheia primară corespunzătoare din fiecare din tabelele date.

În figura „e” se pot observa relațiile definite în baze de date pe care se bazează această aplicație.

În Access, cheia primară a unei tabele se definește la proiectarea tabelei. Cheile candidate nu se definesc explicit, ci pot fi testate doar la introducerea datelor. Cheile străine permit stabilirea de asocieri între tabele și se definesc în două etape. Legarea tabelelor și extragerea datelor implică legarea mai multor prin relații între date, în vederea creării unor tabele temporale, stocarea în memoria calculatorului sau în fișiere temporale pe disc, care conțin datele alese de utilizator. Access folosește interogări pentru legarea tabelelor și alegerea datelor care trebuie stocate într-un tabel temporal numit obiect recordset. Un obiect recordset cuprinde datele care rezultă din executarea interogării; obiectele recordset se numesc tabele virtuale pentru că ele sunt stocate în memoria calculatorului, nu în fișiere de tip baze de date

Formularele din Access creează interfața cu utilizatorul pentru tabele. Deși se poate folosi modul de afișare Table și modul de afișarea Query pentru a efectua un număr mare din funcțiile procesate de formulare, formularele prezintă avantajul prezentării datelor într-un mod organizat și atrăgător. Se pot rearanja pozițiile câmpurilor într-un formular în așa fel încât introducerea datelor sau operațiilor de editare pentru o singură înregistrare să urmeze ordinea de la stânga la dreapta și de sus în jos. Formularele permit crearea unor selecții cu opțiuni multiple pentru câmpurile care folosesc coduri abreviate pentru reprezentarea unui set de valori permise. Un formular bine configurat mărește viteza de introducere a datelor și reduce erorile de culegere.

Microsoft Access oferă posibilitatea creării de rapoarte care sunt niște obiecte special concepute pentru a tipării informații. Orice raport poate fi vizualizat în trei moduri:

modul design, în care programatorul stabilește sursa de date a raportului, forma sa, elemente de design, informații legate de antetul de raport, antetul de pagină etc. Se pot aplica grupări ale informațiilor, calcula sume, medii, se pot număra înregistrări, se pot ordona informații.

modul preview, în care se poate vizualiza raportul în forma în care va fi tipărit. În acest moment datele din sursa de date ale raportului vor figura în acesta.

modul tipărit, în care informațiile vor fi tipărite la imprimantă. Raportul va arăta ca în modul preview.

Aplicația are definite niște rapoarte și o procedură numită Preview_Click, procedură care se execută la evenimentul de click.

Private Sub Preview_Click()

If IsNull([BeginDate]) Or IsNull([EndDate]) Then

MsgBox "You must enter both beginning and ending dates."

DoCmd.GoToControl "BeginDate"

Else

If [BeginDate] > [EndDate] Then

MsgBox "Ending date must be greater than Beginning date."

DoCmd.GoToControl "BeginDate"

Else

Me.Visible = False

End If

End If

End Sub

Figura „f”

Un alt avantaj folosit în această aplicație și foarte important este cel referitor la posibilitatea de a ascunde unele câmpuri din tabelă, iar la vizualizarea tabelei în Design View aceste câmpuri nu sunt vizibile

Din meniul Format Hide și Unhide Column se poate face acest artificiu. În Figura „f” este prezentată fereastra de Unhide Column; din această fereastră se pot seta ca coloanele ascunse să fie vizibile din nou

În final voi prezenta una din ferestrele aplicației și anume cea de vizualizare și modificare a informațiilor referitoare la produse. În această fereastră se pot vizualiza produsele deja existente în tabela care reține informațiile legate de produse cu ajutorul bării de navigare din josul ferestrei. Această fereastră poate fi vizualizată mai pe larg în figura „g”.

Figura „g”

Pentru a introduce informații noi în tabelă, utilizatorul trebuie să se poziționeze pe ultima înregistrare, înregistrare care este goală, și să completeze informațiile care trebuiesc reținute despre produsul care se dorește a fi adăugat în nomenclatorul de produse.

5.2 Exportarea tabelelor din aplicatia Microsoft Access in Microsoft SQL Server

Capitolul VI: Concluzii

Principalul obiectiv al mediului baze de date este de a oferi o mulțime de date consistente, exacta, accesibila , sigura, controlabila si extensibila pentru a servi nevoile de informație ale unei comunități de utilizatori in creștere. Investiția inițiala in software DBMS, efortul de proiectare baza de date logica si fizica, persoanele superpregătite, toate își vor avea justificarea deși poate nu imediat evidența. Beneficiul real al mediului de baze de date este calitatea îmbunătățită a datelor, precum si disponibilitatea si costurile reduse pentru suportarea in continuare a nevoilor de date a utilizatorilor.

Succesul tehnicilor de modelare de date comerciale certifica recunoașterea crescânda a importantei modelarii datelor in comunicații si in descoperirea datelor. Modelarea datelor este folosita rutinier pentru :

a creste înțelegerea datelor si a semnificației lor de către o organizație

a documenta resursele de date

a evalua din exterior pachete software

a planifica sisteme informatice

a proiecta sistemele informatice

a integra resursele de date

a proiecta si implementa baza de date fizice.

Modelarea datelor logice este o parte esențiala a ciclului de viata al proiectului baza de date si este folosita pentru a documenta mediile existente si pentru a planifica viitoarele resurse de date. Modelarea datelor este folosita, de asemenea, pentru a dezvolta proiecte modele de date si pentru a integra aceste modele intr-o schema conceptuala de dezvoltare, care este un scop special al modelului de date logice. Rezultatul modelarii datelor pot fi apoi transformate in proiectări de baze de date fizice.

Din punct de vedere fizic, exista o varietate de abordări pentru a implementa baze de date relaționale. Cele doua alternative inițiale sunt de a folosi un software relațional sau un hardware specializat pentru gestionarea bazelor de date relaționale. Aceste alternative pot fi combinate pentru a distribui relațiile pe mai multe calculatoare, ca o baza de date distribuita. Toate DBMS-urile relaționale software disponibile oferă in general același nivel de suport end – user. Ele diferă, totuși, in abordările lor pentru a localiza datele in memorie si in gestionarea accesului la date. Abordările introduse in text includ o relație de baza pe fișier , mai multe relații de baza pe fișier, mai multe relații de baza in mai multe fișiere si mai multe fișiere pentru o relație de baza.

Mașinile baza de date sunt calculatoare specializate pentru a gestiona bazele de date. Astăzi ele suporta toate modelul relațional si deci sunt candidate pentru implementarea bazelor de date relaționale.

Obiectivele lor sunt de a reduce cerințele de prelucrare pentru calculatoarele cu scop general si de a îmbunătății performanța sistemelor de baze de date.

Bazele de date distribuite memorează partițiile relațiilor pe mai multe calculatoare, conectate printr-o rețea de comunicații. O baza de date este distribuita fizic pentru a imbunatatii performantele sistemelor baze de date in medii descentralizate.

Dezvoltarea modelului relațional a construit o secvența de jaloane in cercetarea gestionarii datelor. Simplitatea modelului relațional si separarea vederilor de implementare si de utilizator l-au făcut atractiv pentru cel puțin 15 ani, in primul rând in comunitatea cercetătorilor si apoi pe piața.

Cele mai bune caracteristici ale modelului relațional sunt :

viziunea sa simpla, tabelara asupra datelor;

mulțimea completa de operatori de manipulare date;

separarea modelului logic de implementare fizica;

Dezavantajele de baza ale modelului relațional sunt:

suprareîncărcarea semantica, intr-o singura structura tabelara se reprezintă o varietate de construcții de modelare de date logice;

demonetizarea, prin caracterizarea DBMS-urilor comerciale ca „relaționale” chiar daca ele nu utilizează anumite restricții ale modelului relațional, ca de exemplu integritatea referențială;

operatorii relaționali care sunt la un nivel procedural, de programator si trebuie acoperiți prin comenzi de nivel înalt, care sunt mai ușor de folosit de către nespecialiști;

implementarea ineficienta, relativ la alte proiectări , pentru anumite tipuri de structuri de date.

Prima problema poate fi ameliorata prin folosirea unei tehnici de modelare a datelor logice in modelul relațional. A doua problema nu tine chiar de modelul relațional ci de folosirea de către industrie a terminologiei. La a treia problema este mai mult de lucru, iar a patra se rezolva prin specializarea hard-ului si soft-ului baze de date. DBMS-urile relaționale comerciale continua sa aibă probleme de performanta in mediile baze de date mari si complexe.

Bibliografie

Ionescu, Felicia, Baze de date relaționale și aplicații, Editura Tehnică, 2004.

Titus Slavici, Elemente fundamentale ale proiectarii si fabricarii asistate pe calculator, Eurobit 1999.

Gheorghe Petrov, Ioan Despi, Robert Reisz, Aurel Stepan, Teoria generala a bazelor de date, Editura MIRTON Timișoara 2000.

Győrödi Cornelia, Pecherle George, “Baze de date relaționale. Teorie și aplicații în Oracle“, Editura Universitati, 2008.

Győrödi Cornelia, Győrödi Robert, Baze de date relationale. Concepte avansate ,Editura Treira, 2000.

Aurel Stepan , G. Priboi, Sisteme informatice distribuite, Universitatea din Timișoara, 1985.

Tsichritzis, D.;Klug, A. The ANSI/X3/SPARC DBMS frame work report of the study group of database management system, Info System, 1978.

Astrahan, M.M. e.a. (1976) Sistem R: relational approach to data base management, ACM Trans. Database Systems 1 (1976).

Brodie, M.L; Schmidt, J.W. (ed.) (1982) Final report of the relational database task group ANSI/X3/SPARC/DBSSG, ACM SUGMOD Record 12 (1982).

Gabriela V. Mnerie, Dumitru Mnerie, Tehnologii Industriale Specifice, Editura Eurostampa, Timisoara 2013.

Mircea Vladutiu, Tehnica Testarii Echipamentelor Automate de Prelucrare a Datelor, Editia a II-a, Editura Solmess, Timisoara 2012.

Titus Slavici, Dinu Gubencu, Ioan Groza, Calculatoare personale: initiere in utilizare, Editura Fundatie „Ioan Slavici”, 2003.

Titus Slavici, Conducerea cu calculatoare, Politehnică 1996.

Chamberlin, D.D. e.a. (1976) SEQUEL 2 : An unifiedapproach to data definition, manipulation and control, IBM J. of. Res. And Developement 20 (1976).

Codd, E.F. (1979) Extending the database relational model to capture more meaning, ACM Trans. Database System 4 (1979).

Date, C.J. (1982) A formal definition of the relational model, ACM SIGMOD Record 13 (1982).

Cohen, J. (1981) Garbage collection of linked data structures, ACM Computing Surveys, 13.

Comer, D. (1979) The ubiquitous B-tree, ACM Computing Surveys,11.

Knuth, D.E. (1973) The Art of Computer Programming, Vol 3: Sorting and Searching , Addison Wesley, Reading, Mass.

Loomis, M.E.S.(1983) Data Management and File Processing, Prentice Hall, Englewood Cliffs, N.J.

Tannenbaum, A.M.; Augestein, M.S. (1981) Data Structures Using Pascal, Prentice Hall, Englewood Cliffs.

Hsiao, D. (1983) Advanced Database Machine Architecture, Prentice Hall, Englewood Cliffs, NJ.

Neches, P.M. (1984) Hardware support for advanced data management system, Computer, 17.

RDMS Design Principles. RDMS Reference Guide, MIT, Cambridge, Mass.

Stonebraker, M. e.a. (1974) The design of implementation of INGRES, ACM Transaction on Database Systems, 1.

Todd, S. (1975) An efficient implementation for large relational databases, Proc. International Conf. on Very Large Databases, Framigham Mass.

Cârstoiu, Dorin, Baze de date relaționale, Editura Printech,1999.

Rădulescu, Florin, Baze de date în Internet, Editura Printech, 2000.

Baltac, Vasile, ECDL-Excel, Access, PowerPoint în 20 lecții și 75 de simulări, Editura Andreco, 2003

www.bmc.com

Browne, Allen, Balter Alison, Bazele Access 95, Editura Teora, 1999

Pribeanu, Costin, Baze de date și aplicații, Editura MatrixRom, 2000

Pascu, C., Pascu A., Totul despre SQL, Editura Tehnică, 1994

Bibliografie

Titus Slavici, Conducerea cu calculatoare, Politehnică 1996

Titus Slavici, Elemente fundamentale ale proiectarii si fabricarii asistate pe calculator, Eurobit 1999

Gheorghe Petrov, Ioan Despi, Robert Reisz, Aurel Stepan, Teoria generala a bazelor de date, Editura MIRTON Timișoara 2000.

Győrödi Cornelia, Pecherle George, “Baze de date relaționale. Teorie și aplicații în Oracle“, Editura Universitati, 2008

Győrödi Cornelia, Győrödi Robert, Baze de date relationale. Concepte avansate ,Editura Treira, 2000.

Aurel Stepan , G. Priboi, Sisteme informatice distribuite, Universitatea din Timișoara, 1985.

Tsichritzis, D.;Klug, A. The ANSI/X3/SPARC DBMS frame work report of the study group of database management system, Info System, 1978.

Astrahan, M.M. e.a. (1976) Sistem R: relational approach to data base management, ACM Trans. Database Systems 1 (1976).

Brodie, M.L; Schmidt, J.W. (ed.) (1982) Final report of the relational database task group ANSI/X3/SPARC/DBSSG, ACM SUGMOD Record 12 (1982).

Chamberlin, D.D. e.a. (1976) SEQUEL 2 : An unifiedapproach to data definition, manipulation and control, IBM J. of. Res. And Developement 20 (1976).

Codd, E.F. (1979) Extending the database relational model to capture more meaning, ACM Trans. Database System 4 (1979)

Date, C.J. (1982) A formal definition of the relational model, ACM SIGMOD Record 13 (1982).

Cohen, J. (1981) Garbage collection of linked data structures, ACM Computing Surveys, 13.

Comer, D. (1979) The ubiquitous B-tree, ACM Computing Surveys,11.

Knuth, D.E. (1973) The Art of Computer Programming, Vol 3: Sorting and Searching, , Addison Wesley, Reading, Mass.

Loomis, M.E.S.(1983) Data Management and File Processing, Prentice Hall, Englewood Cliffs, N.J.

Tannenbaum, A.M.; Augestein, M.S. (1981) Data Structures Using Pascal, Prentice Hall, Englewood Cliffs.

Hsiao, D. (1983) Advanced Database Machine Architecture, Prentice Hall, Englewood Cliffs, NJ.

Neches, P.M. (1984) Hardware support for advanced data management system, Computer, 17.

RDMS Design Principles. RDMS Reference Guide, MIT, Cambridge, Mass.

Stonebraker, M. e.a. (1974) The design of implementation of INGRES, ACM Transaction on Database Systems, 1.

Todd, S. (1975) An efficient implementation for large relational databases, Proc. International Conf. on Very Large Databases, Framigham Mass.

Alcatel-Lucent :

http://www3.alcatel-lucent.com/wps/DocumentStreamerServlet?LMSG_CABINET=Docs_and_Resource_Ctr&LMSG_CONTENT_FILE=Financial_Info/Income_Statements/IR-2013-ALU-20-F.pdf

http://www.sustainability-indices.com/images/140911-djsi-review-2014-en-vdef.pdf

"Thomson Reuters Names the 2014 Top 100 Global Innovators". Retrieved 18 April 2015.

"Alcatel-Lucent announces Chairman Serge Tchuruk and CEO Pat Russo to step down" (Comunicat de presa). Alcatel-Lucent. 2008-07-29. Accesat 2009-04-28.

"Alcatel-Lucent fourth quarter 2010 earnings" (Press release). Alcatel-Lucent. 2011-02-10.

2012 Annual Report on Form 20-F

"Alcatel-Lucent reportedly to reduce workforce by 10,000 jobs". Accesat October 9, 2013.

"Alcatel-Lucent Builds Future Around IP". Light Reading. Retrieved 18 April 2015.

"Nokia agrees to buy Alcatel-Lucent for $16.6 billion". The Verge. Retrieved 15 April 2015.

lucent.com/wps/portal/!ut/p/kcxml/04_Sj9SPykssy0xPLMnMz0vM0Y_QjzKLd4w3sfQGSYGYRq6m-pEoYgbxjggRX4_83FT9IH1v_QD9gtzQiHJHR0UAdXXZMA!!/delta/base64xml/L3dJdyEvd0ZNQUFzQUMvNElVRS82X0FfNUxJ "Alcatel-Lucent History". Company Overview. Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"Alcatel-Lucent Merger Timeline". News Features. Alcatel-Lucent. 2006. Retrieved 2010-04-25.

Leers, Kaj (2007-12-18), "Draka to pay 209 mln eur to Alcatel-Lucent for 49.9 pct stake in Comteq JV", Forbes, retrieved 2010-07-28

"Dassault Aviation completes the acquisition of Alcatel-Lucent's stakes in Thales". Press Release. Alcatel-Lucent. 2009. Retrieved 2010-04-25.

"Alcatel-Lucent acquires OpenPlug, a cross-platform mobile software development tool provider". Press Release. Alcatel-Lucent. 2010. Retrieved 2010-11-04.

"Alcatel-Lucent sells Genesys for $1.5bn". October 19, 2011.

"NOKIA AND ALCATEL-LUCENT TO COMBINE TO CREATE AN INNOVATION LEADER IN NEXT GENERATION TECHNOLOGY AND SERVICES FOR AN IP CONNECTED WORLD". Nokia. Retrieved 15 April 2015.

"Merger of Nokia With Alcatel-Lucent Could Put Pressure on Prices". Wall Street Journal. 14 April 2015. Retrieved 15 April 2015. (subscription required)

"Thomson part of CGE".

"Alcatel is formed" (PDF).

"Cables dy Lyon subsidiary of Alcatel".

"CGE privatized".

"Alcatel-Lucent Company History".

"New York Times coverage of Rockwell unit sale". The New York Times. 1991-07-13.

"CGE acquires Rockwell".

"Alcatel and Lucent Talks".

Schiesel, Seth (1998-06-05). "Alcatel acquires DSC for $4.4 billion". NY Times.

"Alcatel Buys Packet Engines". Wired. 1998-10-13.[dead link]

"Nexans Press Release". Oct 9, 2000.

"Draka Press Release" (PDF). May 17, 2004.

"TCL Unit to Buy 45% Stake of Mobile-Phone Venture From Alcatel". Bloomberg. 2005-05-16.

"History of AT&T and Television". AT&T.

1947 Western Electric Annual Report. Western Electric. 1947. p. 5.

"coversheet for technical memoranda" (PDF). Retrieved 2012.

"AT&T Milestones".

Bell Laboratories Record. June 1980. p. 189.

"Long-Haul Lightwave Transmission System".

Lucent Technologies to Acquire Yurie Systems for $1 Billion – New York Times. Nytimes.com (1998-04-28). Retrieved on 2013-08-22.

Jeong Kim Biography – Academy of Achievement. Achievement.org (2008-08-18). Retrieved on 2013-08-22.

Ben Rooney (February 7, 2011). "Alcatel-Lucent Shrinks Cell Tower". The Wall Street Journal: Technology. Retrieved 2012-01-25.

Alcatel-Lucent sells Genesys for $1.5bn Financial Times, 19 October 2011

"Nokia just bought Alcatel-Lucent for $16.6 billion". Engadget. 15 April 2015. Retrieved 15 April 2015.

"Nokia to buy Alcatel-Lucent to grow in telecom". Reuters. 15 April 2015. Retrieved 15 April 2015.

"[1]." Alcatel-Lucent Fast Facts. Retrieved on 31 July 2014 "Headquarters 148/152 route de la Reine 92100 Boulogne-Billancourt, France"

"[2]." Alcatel-Lucent Fact Sheet. Retrieved on 17 August 2011 "Headquarters 3 av. Octave Gréard 75007 Paris, France"

"la tête dans les étoiles." Le Journal du Net. Retrieved on 8 July 2010.

"Regional Groups". Company Overview. Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"ALU MEA". Alcatel-Lucent. Retrieved 2009-06-02.

Alcatel-Lucent's board of directors http://www.alcatel-lucent.com/about/governance

Leadership team, Alcatel-Lucent's website

"Innovation". Alcatel-Lucent. 2009. Retrieved 2009-04-28.

"AT&T History".

"IEEE Global History Network: Transistors".

31 Terabits por segundo: Alcatel-Lucent bate récord mundial de transmisión de datos submarina. Businesscol.com (2013-07-23). Retrieved on 2013-08-22.

"Technology Review 2012". Technology Review. 2012.

"Global Mobile Awards 2012". Global Mobile Congress. March 2012.

FCPA Blog (28 December 2010). "Alcatel-Lucent Settles Bribery Case". FCPA Blog.

U.S. Securities and Exchange Commission (27 December 2010). "SEC Charges Alcatel-Lucent with FCPA Violations". U.S. Securities and Exchange Commission.

United States District Court for the Southern District of Florida (27 December 2010). "Securities and Exchange Commission v Alcatel-Lucent, S.A." (PDF). U.S. Securities and Exchange Commission.

Department of Justice, Office of Public Affairs (27 December 2010). "Alcatel-Lucent S.A. and Three Subsidiaries Agree to Pay $92 Million to Resolve Foreign Corrupt Practices Act Investigation". The United States Department of Justice.

Pleading Paper

"Microsoft faces $1.5bn MP3 payout". BBC News. 2007-02-22. Retrieved 2010-04-23.

"Microsoft hit with $1.5 billion patent verdict". CNET. CBS Interactive. Retrieved 18 April 2015.

Bangeman, Eric (2007-08-06). "Judge tosses verdict, $1.52 billion award in Microsoft MP3 patent case". arstechnica. Archived from the original on 29 August 2007. Retrieved 2007-08-07.[dead link]

Broache, Anne (2007-03-02). "Microsoft wins in second Alcatel-Lucent patent suit". CNET News.com. Archived from the original on 5 March 2007. Retrieved 2007-03-04.

Montalbano, Elizabeth (2007-03-03). "One Patent Claim Against Microsoft Dropped". Retrieved 2007-03-04.

"Newegg nukes "corporate troll" Alcatel in third patent appeal win this year". Ars Technica. Retrieved 18 April 2015.