IT sviestapika » datubāzes

www.atlaizuklubs.lv SQL kļūda

Kaspars — Wed, 29 Dec 2010 07:54:21 +0000

Šorīt apmeklējot www.atlaizuklubs.lv atklājās medusmaize- SQL kļūdas paziņojums no kuras var izsecināt daļu no datubāzes uzbūves.
Pēc visa spriežot uz servera aptrūkās vieta.
Konkrētā gadījumā izskatās pēc divām klasiskām kļūdām:
1. Nav atslēgta kļūdu izvadīšana (nepieciešama izstrādes posmā, bet ne produkcijas serveros).
2. Un nebija uzstādīts servera disk space monitorings (alerts).

Uzņēmuma informācijas aizsardzība vai kā izsargāties no datu noplūdes

Kaspars — Thu, 16 Sep 2010 18:52:45 +0000

Kādu laiku domāju, ka pasargāt uzņēmuma informāciju no negodprātīgiem lietotājiem ir gandrīz neiespējami- izņemot gadījumus, ja tiek ieviesta pilnīga kontrole- bez mobīliem telefoniem, visu laiku tiek veikta videonovērošana, internets nogriezts un USB pieslēgvieta atslēgta, veikta personas fiziska pārbaude, utt.
Šādas abnormālas pārbaudes lielākoties neder un nav ekonomiski pamatotas lielākai daļai uzņēmumu.
Parokot šajā tēmā dziļāk atklāju robu zināšanās- DLP (Data Leak Prevention) programmas, kas nodarbojas ar uzņēmumā esošās informācijas analīzi un datu noplūdes prevenciju.
Šīs programmas iedalās trijās daļās:

meklē informāciju datu glabātuvēs (pc cietajos, serveros, utml),
to, kuru lietotājs pārsūta netā un
kā lietotāji strādā ar informāciju (kopē, utt).

We also need to discuss what we mean by protecting data at rest, data in motion, and data in use.
Data-at-rest includes scanning of storage and other content repositories to identify where sensitive content is located. We call this content discovery. For example, you can use a DLP product to scan your servers and identify any documents with credit card numbers. If that server isn’t authorized for that kind of data, the file can be encrypted or removed, or a warning sent to the file owner.
Data-in-motion is sniffing of traffic on the network (passively or inline via proxy) to identify content being sent across communications channels. For example, this includes sniffing emails, instant messages, or web traffic for snippets of sensitive source code. In motion tools can often block based on central policies, depending on the type of traffic.
Data-in-use are typically endpoint solutions that monitor data as the user interacts with it. For example, they can identify when you attempt to transfer a sensitive document to a USB drive and block it (as opposed to blocking use of the USB drive entirely). Data in use should also detect things like cut and paste, or use of sensitive data in an unapproved application (such as someone attempting to encrypt data to sneak it past the sensors).

Diezgan labs raksts, kas apraksta pēc kāda principa šādas programas strādā ir publicēts:
te
te
te

Pret katru no šiem veidiem mazliet zinošs cilvēks var cīnīties, bet vismaz no lielākās daļas (arī no gudriem, bet neuzmanīgiem) tas var paglābt.

Un ar https (gmail, utml) savienojumiem cīnās- uz lokālā datora izveidojot sertifikātu un tiek izveidots drošs savienojums starp PC (aģentu) un DLP, līdzīgi kā MITM uzbrukumā.

Data in use gadījumā lokālais aģents skatās ko lietotājs dara ar datiem, piemēram, šifrētus datus neļauj kopēt uz USB, ja kopēšanas laikā tiek noņemta šifrēšana (FAT failsistēma, utml).

Nu ko- karogs rokā..

Piedāvājums arī plašs- sākot no oracle, symantes, utt.

Jānodefinē tikai ko nepieciešams aizsargāt un jāgatavo tikai $.

Internetā rakstīts, ka licenču cenas pēdējo 3 gadu laikā arī ir nokritušās no 100-140$, līdz 40-60$ par katru datoru.

Datubāzes normālformas vai kā projektēt pareizi(papildināts)

Kaspars — Sat, 18 Oct 2008 10:10:34 +0000

Kam tas vispar ir vajadzīgs?

Izveidojot datubāzi, kura atbilstu vismaz pirmajām trijām normālformā, mēs atrisinām problēmas, kuras ir saistītas ar informācijas dublēšanos, kā arī ar iespējamām loģiskām un strukturālām uzbūves problēmām, kuras mēdz dēvēt arī par datubāžu anomālijām.

Mīnus normalizācijai ir tāds, ka, tas prasa tabulu sadalīšanu vairākās citās tabulās. Tādēļ, lai pēc tam izgūtu datus no tās ir vajadzīgi vairāku tabulu apvienojumi ar vaicājumiem, kas var samazināt jautājumu izpildes ātrumu.

Anomālijas( problēmas) datubāzēs var būt šādas:

atjauninājuma anomālija
ievietošanas anomālija
dzēšanas anomālija

Atjauninājuma anomālijas piemērs:

Piemēram ir tabula, ar Lietotaja ID, Adresi un Auto. Gadījumā ja lietotājam ir divas vai vairāk automašīnas rodas problēmas:

Lietotaja ID	Adrese	Auto
1	Rīga, Brīvības 5	Audi
2	Rīga, Brīvības 55	BMW
2	Rīga, Brīvības 55	Audi
3	Dobele, kautkas	VW

veicot labošanu lietotāja adresē ir jāatjauno uzreiz divi ieraksti
ja labošanas rezultātā notiek kļūme un nomainās adrese tikai vienā ierakstā un otrā paliks vecā informācija, nebūs iespējams patteikt, kura adrese īsti ir: pirmajā vai otrajā rindiņā

Iespējamais kļūdainās tabulas izskats:

Lietotaja ID	Adrese	Auto
1	Rīga, Brīvības 5	Audi
2	Rīga, Brīvības 55	BMW
2	Rīga, Brīvības 40	Audi
3	Dobele, kautkas	VW

Ievietošanas anomālija:

Tā rodas gadījumos, kad kādu informāciju nevar vispār ievietot,

piemēram, tabula, kura satur datus par reģistrētiem auto(pieņemot, ka katram auto ir jābūt valsts nr. – visi lauki ir obligāti):

ID	Marka	Sasijas num	Valsts nummurzīme
1	Audi	12345	LV-1111
2	BMW	23456	LV-1112
3	VW	34567	LV-1113

Ievietošanas anomālija rodas, tad, kad ir jāievieto dati par vēl neriģestrētu auto, jo tam vēl nav piešķirts valsts nummurs, piemēram, pievienot:

ID	Marka	Sasijas num
4	VW	45678

Tādēļ šādā struktūrā, šādu irakstu ievietot nevar.

Dzēšanas anomālija:

Šāda veida nomālija rodas gadījumā, kad viena fakta dzēšanas rezultātā tiek pazaudēta informācija pa visma par citu faktu, piemēram, ja tiek dzēsta valsts numurzīme LV-1111no datubāzes(iepriekšējais piemērs)(delete from table where vn=lv-1111), tad automātiskie tik dzēsta informācija arī par reģistrēto pašu auto, kas nedrīkstētu notikt.

Normālformas :

1 NF

Tabula atbilst pirmajai normālformai tad un tikai tad, kad visi tās kolonas(domēni) satur atomāras(nedalāmas vērtības)

Ja vērtību var sadalī vairākās daļās un tai nezūd jēga tad vērtība ir neatomāra.

Bieži jebkura vērtība var būt gan atomāra, gan neatomāra, pimēram skaitlis: 1234 ir:

atomāra vērtība, ja ar to sparot pin kodu
neatomāra vērtība, ja ar to saprot atsevišķu skaitļu rindu no 1 līdz 4

Skaitļu rinda var būt gan 12 un 34, kā arī samainīta vietām 43 un 21, un skaitļu jēga no tā nemainīsies. Tur pretīm jā samainīs pinkoda skaitļus vietām jēga skaitļiem vairs nav.

Neatomāras bieži pielietojamas vērtības piemērs ir adrese, kuru glabā vienā laukā, piem,

Pilsēta, Iela, Māja

2NF:

tabulai jāatbilst 1 NF

Tabula atbilst otrajai normālformai, ja katrs neprimārais atslēgas lauks ir atkarīgs no visas primārās atslēgas. (Nevis no primārās atslēgas kādas daļās).

Otrajai normālformai nozīme ir tikai realitātēs, kurās ir sarežģīta primārā atslēga(piem, sastāv no diviem laukiem), ja tabulai ir viena konkrēta primārā atslēga, tad tāda tabula jau autmātiski atbilst 2. normālformai, vai vienkāršiem vārdiem- tabulā nedrīkstētu būt divi atribūti, kas varētu būt kā primārie lauki.

*EmployeeID	LastName	FirstName	*ProjectNumber	ProjectTitle
EN1-26	O’Brien	Sean	30-452-T3	STAR manual
EN1-26	O’Brien	Sean	30-457-T3	ISO procedures
EN1-26	O’Brien	Sean	31-124-T3	Employee handbook
EN1-33	Guya	Amy	30-452-T3	STAR manual
EN1-33	Guya	Amy	30-482-TC	Web Site
EN1-33	Guya	Amy	31-241-TC	New catalog

Lai atrisinātu šo problēmu ir jārīkojas sekojoši:

Identificēt atribūtus, kuri ir atkarīgi tikai no primārās atslēgas daļas
Izveidot jaunu realitāti
Ievietot identificētos atribūtus jaunajā realitātē
Izveidot sasaisti starp veco un jauno realitāti

Šinī gadījumā, pirmārā atslēga varētu būt EmployeelID un ProjectNumber, tādēļ tie ir jāsadala:

EMPLOYEES

*EmployeeID	Last Name	First Name
EN1-26	O’Brien	Sean
EN1-33	Guya	Amy
EN1-35	Baranco	Steven
EN1-36	Roslyn	Elizabeth

EMPLOYEES_PROJECTS

*EmployeeID	*ProjectNum
EN1-26	30-452-T3
EN1-26	30-457-T3
EN1-26	31-124-T3
EN1-33	30-328-TC
EN1-33	30-452-T3

PROJECTS

*ProjectNum	ProjectTitle
30-452-T3	STAR manual
30-457-T3	ISO procedures
30-482-TC	Web site
31-124-T3	Employee handbook
31-238-TC	STAR prototype

3NF

Tabula apmierina trešo normālformu, ja tā apmierina otro NF un katrs ne primārais atslēgas lauks ir ne tranzistīvi atkarīgs no primārās atslēgas.

No matemātikas viedokļa nedrīkstētu sanākt, ka x->x un z->x, jo sanāk ka z->y, jo z->x->y.

(Nedrīkst būt situācija, kad ir saikne(attiecības) starp diviem vai vairākiem neprimāriem laukiem)

Piemēram:

id	Vārds	Kabinets	Telefons
1	Kaspars	101	02
2	Jānis	102	03
3	Kaspars	102	03

Šinī situācijā, pieņem, ka:

viens telefona nummurs(nav primārā atslēga) var būt pieslēgts vienā kabinetā(nav primārā atslēga)
un viens cilvēks var atrasties vairākos kabinetos

Rezultātā sanāk, ka telefons ir atkarīgs ne tikai no primārās atslēgas, bet arī no kabineta, kas nav primārā atslēga

Lai atrisinātu šādas problēmas ir jārīkojas šādi:

Jāpārnes savā starpā saistītos noprimāros atribūtus uz jaunu realitāti(tabulu) saglabājot saikni viņu starpā
Izmantot lauku, kurš noteica atkarību kā primāro lauku
Izveidot sasaisti starp veco un jauno realitāti

Tādēļ, lai apmierinātu 3 NF vajadzētu sadaīt šādi

Vārds	Kabinets
Kaspars	101
Jānis	102
Kaspars	102

Kabinets	Telefons
101	02
102	03

Šinī tabulā kabineta nummurs, jau var būt par primāro atslēgu

Kā darbināt linux aplikācijas Windows vidē-andLinux