Какие типы содержатся в реляционных базах данных
 äàííîì ïîñòå ÿ õî÷ó ïîãîâîðèòü íå ïðî ãèãàíòîâ òèïà Google, ßíäåêñ èëè ÂÊ, à ïðî îáû÷íûå êîìïàíèè ñ êîòîðûìè ìû ðàáîòàåì èëè êîòîðûå íå òàê èçâåñòíû.
Íåñìîòðÿ íà êó÷ó çàêîíîâ òèïà ÔÇ-152 óðîâåíü çàùèùåííîñòè ïåðñîíàëüíûõ (è íå òîëüêî) äàííûõ ê ñîæàëåíèþ ïåðåæèâàåò ïî ìîèì íàáëþäåíèÿì íå ëó÷øèå ñâîè âðåìåíà.
Ê ñîæàëåíèþ óòå÷êè âñòðå÷àþòñÿ ïî÷òè íà êàæäîì øàãó, áîëüøèíñòâî ïî ðàáîòå. ß õî÷ó ðàññêàçàòü î íàéäåííûõ ìíîé óÿçâèìîñòÿõ â 2017 ãîäó.
1.
 íà÷àëå ýòîãî ãîäà ïîïðîñèëè ïðîâåðèòü îäíó Windows ïðîãðàììó ñ öåëüþ óçíàòü, ÷òî îíà âîîáùå äåëàåò. Ïðîãðàììà ïîçèöèîíèðîâàëà ñåáÿ êàê îáðàòíàÿ ñâÿçü êëèåíòà ñ ôèðìîé, ñâîåîáðàçíûé òàêîé ÷àò.
Âîîðóæèâøèñü VirtualBox ñ óñòàíîâëåííûì âíóòðè WireShark è äðóãèìè ñðåäñòâàìè ìîíèòîðèíãà íà÷àë ñëåäèòü çà ïðîãðàììîé, èññëåäîâàë ôîðìî÷êè ïðèëîæåíèÿ.  WireShark ïðîìåëüêíóë HTTP-çàïðîñ, îòïðàâëÿþùèé ñîîáùåíèå íà ñåðâåð. Òàê æå îáíàðóæèë è HTTP-çàïðîñ, ïîëó÷àþùèé ñîîáùåíèÿ ñ ñåðâåðà. Íåìíîãî ïîðàçáåæàâøèñü, îáíàðóæèâàåì, ÷òî íèêàêîé àâòîðèçàöèè íà ñòîðîíå ñåðâåðà íåò. Ïîëó÷àåì ñðàçó 2 óÿçâèìîñòè. Ìû ìîæåì ÷èòàòü ñîîáùåíèÿ ëþáîãî ïîëüçîâàòåëÿ, âêëþ÷àÿ, ÷òî ïèøóò àäìèíó, à òàê æå îò èìåíè ïîëüçîâàòåëÿ îòïðàâëÿòü ñîîáùåíèÿ äðóãîìó ïîëüçîâàòåëþ.
2.
Íà ñëåäóþùóþ óÿçâèìîñòü â êîíöå çèìû èëè âåñíîé â 2017 ãîäó ÿ íàòêíóëñÿ ñîâåðøåííî ñëó÷àéíî ñ ïîìîùüþ ðåêëàìû â ßíäåêñ-Äèðåêòå.
Ïîïàëàñü íà ãëàçà ìíå êîíòåêñòíàÿ ðåêëàìà îäíîé ôèðìû, êîòîðàÿ ãîâîðèëà, ÷òî åñòü ôèëèàëû âî ìíîãèõ ãîðîäàõ ÐÔ. ×òî-òî òîãäà ìåíÿ çàèíòåðåñîâàëî è ÿ îòêðûë èõ ñàéò.
Òàì îòêðûë ôîðìó îáðàòíîé ñâÿçè.
Ñ óäèâëåíèåì çàìå÷àþ ïîïàäàþ íà ñàéò áåç äîìåíà, à òîëüêî IP-àäðåñ ñåðâåðà.
Ñòàëî ëþáîïûòíî, à ÷òî ðàáîòàåò íà ýòîé ìàøèíêå? Ïðîâåðÿþ ïîðò FTP è çàõîæó ïîä ãîñòåì. Êó÷à âñÿêèõ ôàéëîâ, ðàáî÷àÿ WEB-ïàïêà ñî ñòðàíèöàìè ñàéòà. Åñòü íåìíîæêî áýêàïîâ. Ñ âèäó ñåðâåð èñïîëüçîâàëñÿ êàê èëè ïîìîéêà èëè êàê òåñòîâûé ñåðâåð.
Îòêðûâàåì ôàéë êîíôèãóðàöèè èç Web-ïàïêè Âèäèì ëîãèí è ïàðîëü îò FTP-äðóãîãî ñåðâåðà.
Ïðîâåðÿåì È ïîïàäàåì óæå âî âòîðîé ñåðâåð
Òàì òîæå ïîäíÿò WEB-ñåðâåð è âîîáùå ôàéëîâ íàìíîãî áîëüøå íà 200 ãèãàáàéò ñ ëèøíèì.  îñíîâíîì ýòî êîíå÷íî áýêàïû áàç, íî è î÷åíü ìíîãî ðàáî÷èõ è ñâåæèõ äîêóìåíòîâ.
Âíóòðè êîíôèãà WEB-ñåðâåðà óæå çàñâå÷èâàåòñÿ è SQL-ñåðâåð ñ ëîãèíîì è ïàðîëåì, êîòîðûé êðóòèòñÿ íà ýòîì ñåðâåðå. È äà. Íà íåãî òîæå ìîæíî ïîïàñòü.
Èòîã: ïîëó÷àåì óòå÷êó â èç êðóïíîé ôèðìû ñ âîçìîæíîñòüþ èñêàçèòü/óíè÷òîæèòü èíôîðìàöèþ è áýêàïû áàç äàííûõ.
3.
Òàêæå â ýòîì ãîäó äëÿ ðàáîòû ïîòðåáîâàëîñü ñîçäàòü ïàðñåð ñàéòà äîâîëüíî áîëüøîé áþäæåòíîé îðãàíèçàöèè äëÿ ôîðìèðîâàíèÿ ÁÄ (îêîëî ìèëëèîíà ñòðîê â 3 òàáëèöàõ), ÷òî áû óìåíüøèòü ðó÷íîé òðóä è ïîñòîÿííûå çàïðîñû ê ñàéòó. Ñàì ñàéò òîæå òîò åùå òîðìîç, ïîýòîìó ñîçäàíèå ïàðñåðà áûëî ëîãè÷íûì ðåøåíèåì, ÷òî áû ïîëó÷èòü ñðàçó ãîòîâûå òàáëèöû è âñåãäà èìåòü èõ ïîä ðóêîé.
 ãîëîâå âìåñòå ñ àëãîðèòìîì ïàðñåðà è êîëè÷åñòâî ñðîê êîäà ðîñëà òàêæå ëåíü âñ¸ ýòî äåëàòü. Òîãäà ÿ ðåøèë ïðîâåðèòü òåîðèþ ñ ïðåäûäóùèì ñåðâåðîì. È.. Âû íå ïîâåðèòå! Ñèòóàöèÿ ïðàêòè÷åñêè ïîâòîðèëàñü! Ìû îïÿòü ïîïàëè íà FTP ñåðâåð, íî íà ýòîò ðàç òàì ëåæàë ôàéë VPNRouter_64.vmdk. Âèðòóàëüíàÿ ìàøèíêà.
Íåìíîãî êîëäóåì íàä ôàéëîì è ïîëó÷àåì äîñòóï ê ðàçäåëó âèðòóàëüíîãî äèñêà âíóòðè ìàøèíêè.
Ñàìîå èíòåðåñíîå, ýòî ïàïêà OpenVPN ñ íàñòðîåííîé êîíôèãóðàöèåé è ñåðòèôèêàòàìè.
Êîïèðóåì íà ñâîé êîìï, ïîäêëþ÷àåìñÿ, è Áèíãî! Ìû âíóòðè çàùèùåííîé ñåòè.
Ñìîòðèì êàêîé íàì ïðèñâîèë ñåðâåð âèðòóàëüíûé IP.
Îòêðûâàåì òåðìèíàë, çàïóñêàåì nmap ñêàíèðóåì âñþ ïîäñåòü íà 80,21,1433 ïîðòû.
Åñòü íåñêîëüêî êîìïüþòåðîâ ñ òàêèìè îòêðûòûìè ïîðòàìè!
È îïÿòü íàñ ðàäîñòíî âñòðå÷àåò FTP áåç ïàðîëÿ íà îäíîì èç ñåðâåðîâ!
À äàëüøå êëàññèêà. Îòêðûâàåì Web.config, ïîëó÷àåì ñòðîêó ïîäêëþ÷åíèÿ ê ñåðâåðó è ñ ïîìîùüþ dBeaver ìû ïîëó÷àåì äîñòóï ê áàçå äàííûõ âíóòðè ñåòè. ×òî åùå èíòåðåñíåå, äàííàÿ êîìáèíàöèÿ ïîäîøëà è íà äðóãèå SQL-ñåðâåðà âíóòðè ýòîé ñåòè. Îäèí ïàðîëü íà âñå ñåðâåðà (âñåãî èõ áûëî 3-5 ñåðâåðîâ, óæå íå ïîìíþ). È ýòî äîâîëüíî êðóïíàÿ áþäæåòíàÿ îðãàíèçàöèÿ äëÿ íàøåãî ðåãèîíà!
Îïÿòü æå âîçìîæíîñòü ïîëîæèòü ñàéòû, ñîâåðøèòü óòå÷êó ïåðñîíàëüíûõ äàííûõ (ÿ òàì ñåáÿ íàø¸ë), èñêàçèòü/óäàëèòü.
Ñàìè ïåðñîíàëüíûå äàííûå ìíå óæå íå èíòåðåñíû. ß ñ íèìè ðàáîòàþ êàæäûé äåíü, äîïóñê ê áàçå ñâîåãî ðåãèîíà (íó èëè áîëüøåé å¸ ÷àñòè) ó ìåíÿ åñòü è òàê.
4.
Åùå îäèí ñëó÷àé îïÿòü æå íà ðàáîòå, îïÿòü æå â ýòîì ãîäó.
Äðóãàÿ áþäæåòíàÿ îðãàíèçàöèÿ äàëà VPN (L2TP) äîñòóï è ïðîãðàììêó êîòîðàÿ ðàáîòàåò ñ èõ ñåðâåðîì, îáìåí ñ áàçîé äàííûõ.
 òàêîì ðåæèìå ìû óæå ðàáîòàåì äàâíî, íî ïðîãðàììèñò íàïèñàâøèé ïðîãðàììó óæå óâîëèëñÿ, à íåóäîáñòâà ñ ïðîãðàììîé ïðîÿâëÿþòñÿ âñå ñèëüíåå è ìûñëè íàïèñàòü ñâîþ ïðîãðàììó òèïà ïëàãèíà èëè õîòÿ áû íóæíûå ñêðèïòû. È òîãäà ÿ ðåøèë ïðîâåñòè îäèí ýêñïåðèìåíò, à èìåííî ïîïðîáîâàòü ïîäêëþ÷èòüñÿ íå ÷åðåç èõ ïðîãó, à ÷åðåç ðåäàêòîð ÁÄ. Âûäåðãèâàþ, ïî êàêîìó àäðåñó èõ ïðîãðàììà ñòó÷èòñÿ, âáèâàþ â ðåäàêòîð ÁÄ, è ñåðâåð íàñ âïóñòèë! Åìó õâàòèëî ïîäêëþ÷åíèÿ ïî VPN è äîâåðèòåëüíîå ñîåäèíåíèå! Ìû îïÿòü ïîëó÷àåì äîñòóï ê ñåðâåðó êî âñåì áàçàì, êîòîðûå òàì íàõîäÿòñÿ ñî âñåìè âûòåêàþùèìè, êóäà ïî èäåå ìû íå äîëæíû áûëè ïîïàñòü.
5.
Ïîõîæàÿ ñèòóàöèÿ è â ñàìîé êîðïîðàòèâíîé ñåòè, îïÿòü æå â ýòîì ãîäó.
Äàëè ïðîãðàììó, ôàéë ðååñòðà, âíóòðè êîòîðîãî Ëîãèí sa, ïàðîëü 111111As . Äîñòóï èç âíåøêè Íó õîòü íå íà ñòàíäàðòíîì ïîðòó. À íà íåì òàê æå êðóòèòüñÿ ïåðñîíàëüíàÿ èíôîðìàöèÿ! Ëþáîé àäìèí èç êîðïîðàòèâíîé ñåòè ñóòè ìîæåò óâèäåòü èíôó äðóãîãî ôèëèàëà ÷åðåç SQL-ðåäàêòîð, ê êîòîðîé îí íå äîëæåí èìåòü äîñòóïà, à òàê æå èçìåíèòü/óäàëèòü âñþ ÁÄ! À òî ÷òî èçíà÷àëüíî äàëè äîñòóï áåç çàùèùåííîãî êàíàëà åùå õóæå! Áëàãî ùàñ ïåðåâåëè ïðîãðàììó íà Vipnet, íî ïàðó ìåñÿöåâ íàçàä äîñòóï ïî âíåøíåìó IP åùå áûë, ìîæåò è äî ñèõ ïîð åñòü.
6.
Íåäàâíî ïðîâîäèë èññëåäîâàíèå îäíîãî Android-ïðèëîæåíèÿ (ìîé ïðåäûäóùèé ïîñò), òàì òàêàÿ æå ïëà÷åâíàÿ ñèòóàöèÿ. Ëþáîé øêîëüíèê ìîæåò ïîëó÷èòü äîñòóï ê èíôîðìàöèè áåç àâòîðèçàöèè, ñëèòü áþäæåò íà ÑÌÑ, çàôëóäèòü ÑÌÑ ÷åé íèáóäü òåëåôîí, èñêàçèòü ðåéòèíã, ñëèòü áàçó äàííûõ. Òàê æå ñóùåñòâóåò âîçìîæíîñòü ïîëó÷èòü ïðàâà áàðèñòû ïðîñòûì áðóòîì ïàðîëÿ!
Ýòî âñ¸ ïå÷àëüíî äàìû è ãîñïîäà. Äàâàéòå, ìû áóäåì îòíîñèòüñÿ ê çàùèòå íàøèõ ñåðâåðîâ/ÏÊ/òåëåôîíîâ áîëåå ñåðüåçíî. Äëÿ ïðîíèêíîâåíèÿ âíóòðü íå ïîíàäîáèëèñü íèêàêèå ýêñïëîèòû, õàêåðñêèå íàâûêè. Òîëüêî øòàòíûå ïðîãðàììû è ëþáîçíàòåëüíîñòü.
À ñêîëüêî ïîäîáíûõ ñåðâåðîâ ñ îòêðûòûì äîñòóïîì â èíòåðíåòå? À ñêîëüêî åùå òàêèõ äûðÿâûõ ïðèëîæåíèé â Ìàðêåòå? Íàâåðíî òûñÿ÷è, äåñÿòêè òûñÿ÷.
Âïîëíå âîçìîæíî, Âû òàê æå ñòàëêèâàëèñü ñ ïîõîæèìè ñèòóàöèÿìè, íàäåþñü áåç çëûõ íàìåðåíèé.
Ìíîãèå ýòèì ïðîôåññèîíàëüíî çàíèìàþòñÿ, ïèøóò áîòîâ êîòîðûå ïîëçàþò ïî èíòåðíåòó, ïðîáèâàþò ñòàíäàðòíûå ïîðòû, áðóòÿò ïî ñëîâàðþ, ëîìàþò ðîóòåðû, IP-êàìåðû, óâåëè÷èâàÿ àðìèþ áîòîâ. Ñ òàêèìè áîòàìè âñòðå÷àëñÿ è ÿ, òî÷íåå ìîé Firewall è áûëî çàíÿòíî íàáëþäàòü êàê ïûòàëèñü ïîäîáðàòü ïàðîëü îò ìîåé áàçû ïî ïðèìåðíî ïî 5-10 çàïðîñîâ â ñåêóíäó.
Òàê æå ïîïàäàëèñü áîòû êîòîðûå ïûòàëèñü ëîìàíóòü ìîé FTP è VNC ñåðâåð èç ðàçíûõ ñòðàí.
Îáíàðóæèâ ýòè ïîïûòêè â ëîãàõ, ÿ óáðàë êîìïû çà NAT è ñ òåõ ïîð ÿ äåðæó âñå ïîðòû çàêðûòûìè, îñòàâèâ òîëüêî ïîðò äëÿ VPN-ñîåäèíåíèÿ, à ïðè, íåîáõîäèìîñòè âðåìåííî äîñòóïà äðóãèì ëþäÿì, îòêðûâàþ âðåìåííî èõ íà íåñòàíäàðòíûõ ïîðòàõ. Äëÿ ïîñòîÿííî äîñòóïà èñïîëüçóþ OpenVPN è ãåíåðèðóþ ñåðòèôèêàòû íà êàæäîå óñòðîéñòâî.
Èòàê. Äëÿ ìèíèìàëüíîé áåçîïàñíîñòè:
1. Íå äåðæèòå FTP ñåðâåð ñ âîçìîæíîñòüþ ïîäêëþ÷àòüñÿ àíîíèìóñîì. Íå äåðæèòå íà FTP êàêóþ ëèáî èíôó, ïîçâîëÿþùàÿ ñêîìïðîìåòèðîâàòü äðóãèå ñåðâåðà. Êîíå÷íî, åñëè ýòî Web-ñåðâåð è ÷åðåç FTP îáíîâëÿåòñÿ åãî ñîäåðæèìîå, òî äàéòå åìó ìèíèìàëüíûå ïðàâà, åñëè åãî âäðóã âñêðîþò.
2. Íå èñïîëüçóéòå ïðîñòûå ïàðîëè, êîòîðûå ìîæíî ëåãêî ñáðóòèòü. Ïîâåðüòå, áîòû íå ñïÿò è ðàíî èëè ïîçäíî ìîãóò ïðèíÿòüñÿ çà âàø ñåðâåð, åñëè îí âèäåí èçâíå.
3. Èñïîëüçóéòå çàùèùåííîå ñîåäèíåíèå. Åñëè ýòî íå ïðåäîñòàâëÿåòñÿ âîçìîæíûì, âåøàéòå ñëóæáû íà íåñòàíäàðòíûå ïîðòû. Òàêèå ïîðòû íàéòè ñëîæíåå è ñêàíèðîâàòü îäèí êîìï îòíîñèòåëüíî äîëãî. Åñëè åñòü íàñòðîåííûé Firewall, òî âïîëíå ìîæåò ñðàáîòàòü òðåâîãà ñêàíèðîâàíèÿ ïîðòîâ è ïðè èõ ïðîçâîíå áîòîì, ôàåðâîë íà÷íåò ïîñûëàòü âñå ïîïûòêè ïîäêëþ÷åíèÿ áîòà â ëåñ, à ïîðòû áîòîì òàê è íå áóäóò íàéäåíû.
4. Åñëè âîçìîæíî, ñòàðàéòåñü â Àíäðîèä-ïðèëîæåíèÿõ øèôðîâàòü âñå HTTP-çàïðîñû. Íàïðèìåð https://127.0.0.1/web?query=vcXGregfds4r5f3r456sdr32vdf-6t è îòâåò ïîëó÷àòü ïðèìåðíî òàêîé æå. ×åðåç ñíèôåð óæå íå áóäåò âèäíà êàêàÿ-ëèáî çàâèñèìîñòü îò çàïðîñîâ è áîëüøèíñòâî ëþáèòåëåé ýòî óæå ìîæåò îñòàíîâèòü.  èäåàëå åùå ïðèêðóòèòü çàùèùåííîå ñîåäèíåíèå, íî ìíîãèõ îñòàíàâëèâàåò, ÷òî SSL-ñåðòèôèêàòû ïëàòíûå. Ìîæíî åùå èñïîëüçîâàòü ñîêåòû.
5. Íå îñòàâëÿéòå â ïðèëîæåíèÿõ ïðàâà àäìèíà, íàïðèìåð â âåá-ïðèëîæåíèÿõ, äåñêòîïíûõ. Ñòàðàéòåñü äàâàòü ìèíèìàëüíûå ïðàâà ïðèëîæåíèÿì. Ôóêíöèè àâòîðèçàöèè æåëàòåëüíî âåøàòü íà ñåðâåð, à äàëüøå ïîñûëàòü òîëüêî ID-ñåññèè, à íå UserID. Ïðè îáìåíå äàííûìè âñåãäà ïðîâåðÿòü àâòîðèçîâàíà ëè ìàøèíà èëè íåò. Îñîáåííî ýòî êàñàåòñÿ Web- è Android-ïðèëîæåíèè.
6. Ïåðèîäè÷åñêè ïðîâåðÿéòå ëîãè ïðèëîæåíèé, à òàê æå ëîã ôàåðâîëà.
7. Ñåðâåðà æåëàòåëüíî ïðÿòàòü çà NAT, à â íåêîòîðûõ ñëó÷àÿõ (íàïðèìåð, åñëè ýòî ñåðâåð ñ ïåðñîíàëüíûìè äàííûìè èëè ãäå ïðîâîäÿòñÿ ôèíàíñîâûå îïåðàöèè) çà äâîéíîé NAT.
8. Íó ïðî ñâîåâðåìåííóþ óñòàíîâêó ïàò÷åé è îáíîâëåíèé, ÿ äóìàþ íå ñòîèò îáúÿñíÿòü.
9. Íó è êîíå÷íî ñëåäèòå çà íîâîñòÿìè î âèðóñíûõ óãðîçàõ, ýïèäåìèÿõ, íîâûõ øèôðîâàëüùèêàõ
Æåëàþ âñåì â ñëåäóþùåì ãîäó ñòàáèëüíûõ ëèíêîâ, îòñóòñòâèå çëîâðåäîâ è õîðîøèõ êëèåíòîâ. Ñäåëàåì íàøè ñåðâåðà, áàçû äàííûõ è ïðèëîæåíèÿ áîëåå çàùèùåííûìè.
Источник
РЕЛЯЦИОННАЯ
БАЗА ДАННЫХ И ЕЕ ОСОБЕННОСТИ. ВИДЫ СВЯЗЕЙ МЕЖДУ РЕЛЯЦИОННЫМИ ТАБЛИЦАМИ
Реляционная
база данных — это совокупность взаимосвязанных таблиц, каждая
из которых содержит информацию об объектах определенного типа. Строка
таблицы содержит данные об одном объекте (например, товаре, клиенте),
а столбцы таблицы описывают различные характеристики этих объектов — атрибутов
(например, наименование, код товара, сведения о клиенте). Записи, т. е.
строки таблицы, имеют одинаковую структуру — они состоят из полей, хранящих
атрибуты объекта. Каждое поле, т. е. столбец, описывает только одну характеристику
объекта и имеет строго определенный тип данных. Все записи имеют одни
и те же поля, только в них отображаются различные информационные свойства
объекта.
В реляционной базе
данных каждая таблица должна иметь первичный ключ — поле или комбинацию
полей, которые единственным образом идентифицируют каждую строку таблицы.
Если ключ состоит из нескольких полей, он называется составным. Ключ должен
быть уникальным и однозначно определять запись. По значению ключа можно
отыскать единственную запись. Ключи служат также для упорядочивания информации
в БД.
Таблицы реляционной
БД должны отвечать требованиям нормализации отношений. Нормализация
отношений
— это формальный аппарат ограничений на формирование таблиц, который
позволяет устранить дублирование, обеспечивает непротиворечивость
хранимых
в базе данных, уменьшает трудозатраты на ведение базы данных.
Пусть создана таблица
Студент, содержащая следу-рэщие поля: № группы, ФИО, № зачетки, дата рождения,
шазвание специальности, название факультета. Такая организация хранения
информации будет иметь ряд недостатков:
- дублирование информации
(наименование специальности и факультета повторяются для каждого студента),
следовательно, увеличится объем БД; - процедура обновления
информации в таблице затрудняется из-за необходимости редактирования
каждой записи
таблицы.
Нормализация таблиц
предназначена для устранения этих недостатков. Имеется три нормальные
формы отношений.
Первая нормальная
форма. Реляционная таблица приведена к первой нормальной форме тогда
и только тогда, когда ни одна из ее строк не содержит в любом своем поле
более одного значения и ни одно из ее ключевых полей не пусто. Так, если
из таблицы Студент требуется получать сведения по имени студента, то поле
ФИО следует разбить на части Фамилия, Имя, Отчество.
Вторая нормальная
форма. Реляционная таблица задана во второй нормальной форме, если
она удовлетворяет требованиям первой нормальной формы и все ее поля, не
входящие в первичный ключ, связаны полной функциональной зависимостью
с первичным ключом. Чтобы привести таблицу ко второй нормальной форме,
необходимо определить функциональную зависимость полей. Функциональная
зависимость полей — это зависимость, при крторой в экземпляре информационного
объекта определенному значению ключевого реквизита соответствует только
одно значение описательного реквизита.
Третья нормальная
форма. Таблица находится в третьей нормальной форме, если она удовлетворяет
требованиям второй нормальной формы, ни одно из ее неключевых полей не
зависит функционально от любого другого неключевого поля. Например, в
таблице Студент (№ группы, ФИО, № зачетной книжки, Дата рождения, Староста)
три поля — № зачетной книжки, № группы, Староста находятся в транзитивной
зависимости. № группы зависит от № зачетной книжки, а Староста зависит
от № группы. Для устранения транзитивной зависимости необходимо часть
полей таблицы Студент перенести в другую таблицу Группа. Таблицы примут
следующий вид: Студент (№ группы, ФИО, № зачетной книжки, Дата рождения),
Группа (№ группы, Староста).
Над реляционными
таблицами возможны следующие операции:
- Объединение таблиц
с одинаковой структурой. Результат— общая таблица: сначала первая, затем
вторая (конкатенация). - Пересечение таблиц
с одинаковой структурой. Результат — выбираются те записи, которые находятся
в обеих таблицах. - Вычитание таблиц
с одинаковой структурой. Результат — выбираются те записи, которых нет
в вычитаемом. - Выборка (горизонтальное
подмножество). Результат — выбираются записи, отвечающие определенным
условиям. - Проекция (вертикальное
подмножество). Результат — отношение, содержащее часть полей из исходных
таблиц. - Декартово произведение
двух таблиц Записи результирующей таблицы получаются путем объединения
каждой записи первой таблицы с каждой записью другой таблицы.
Реляционные таблицы
могут быть связаны друг с другом, следовательно, данные могут извлекаться
одновременно из нескольких таблиц. Таблицы связываются между собой для
того, чтобы в конечном счете уменьшить объем БД. Связь каждой пары таблиц
обеспечивается при наличии в них одинаковых столбцов.
Существуют следующие
типы информационных связей:
- один-к-одному;
- один-ко-многим;
- многие-ко-многим.
Связь один-к-одному
предполагает, что одному атрибуту первой таблицы соответствует только
один атрибут второй таблицы и наоборот.
Связь один-ко-многим
предполагает, что одному атрибуту первой таблицы соответствует несколько
атрибутов второй таблицы.
Связь многие-ко-многим
предполагает, что одному атрибуту первой таблицы соответствует несколько
атрибутов второй таблицы и наоборот.
Источник
Особенности реляционных БД
БД используются для организации хранения данных. Структура реляционной базы данных полностью определяется перечнем названия полей с указанием их типов и свойств. Все записи имеют одинаковые поля, но в них показываются разные свойства объекта. Аналогом реляционной БД считается двумерная таблица. Характерные особенности файла БД:
- Уникальное имя для каждой таблицы.
- Фиксированное число полей.
- На пересечении строки и столбца всегда есть только одно значение.
- Записи отличаются друг от друга хотя бы одним значением элемента.
- Полям присваиваются индивидуальные имена.
- В каждый из столбцов необходимо вставлять однородные данные: целые числа, даты, суммы, имена или фамилии, названия предметов.
Реляционная БД чаще всего не ограничивается одной таблицей. Обычно создаются несколько таблиц со связанной информацией. Это позволяет исполнять более сложные операции над данными. Таблицы реляционной БД обязаны соответствовать требованиям понятия нормализации отношений, то есть ограничениям на формирование, которые позволят избежать дублирования и обеспечат непротиворечивость хранимой информации. Пусть создана таблица «Прокат», содержащая следующие поля: Шифр Клиента, Ф. И. О., Вид устройства, Дата выдачи, Оплата, Срок возврата. Эта организация хранения информации имеет несколько недостатков:
- дублирование информации (вид устройства повторяется для разных клиентов), что увеличивает объём БД;
- для обновления информации требуется обрабатывать каждую запись.
Для устранения этих недостатков необходима нормализация с разделением данных на разные таблицы.
Связывание таблиц
Для любой таблицы реляционной БД задаётся первичный ключ (primary key) — поле или сочетание полей, которые определяют каждую запись. Внешний или вторичный ключ (foreign key) — это одно или несколько полей, ссылающихся на поле primary key другой таблицы.
Составной ключ называется так, потому что создаётся из нескольких полей. При образовании составных ключей не рекомендуется включать в них поля, значения которых точно определяют запись. Например, не следует образовывать ключ, в котором находятся вместе поля «номер паспорта» и «шифр клиента», потому что оба эти атрибута однозначно определяют запись. Поля с повторяющимися в таблице значениями тоже нельзя делать составной частью ключа. По значению ключа возможно найти только одну запись.
Ячейка — это наименьший структурный элемент, который задаёт определённое значение соответствующего поля. Таблицы связываются друг с другом, и поэтому данные могут выбираться сразу из нескольких таблиц. Связь создаётся, если в них присутствуют одинаковые поля. Типы связей:
- один к одному;
- один ко многим;
- многие ко многим.
Связи «один к одному» встречаются довольно редко. «Один ко многим» применяются чаще, например, кассир продаёт много билетов. «Многие ко многим» тоже встречаются часто. Например, студент изучает много предметов. Связи «многие ко многим» нельзя организовывать непосредственно. Для установления отношения необходимо сопоставить каждому primary key внешний ключ, который представляет собой primary key другой таблицы. Реляционные системы базируются на теории реляционной модели, которая включает в себя три аспекта:
- структурный — данные в базе рассматриваются как набор отношений, то есть упорядоченных пар, составленных из заголовка и полей;
- целостности — состоит в проверке правильности согласования данных при обновлении;
- обработки — использование операторов манипулирования таблицами, таких как реляционная алгебра и реляционное исчисление, которые генерируют новые таблицы на основании уже имеющихся.
Управление созданием и использованием БД осуществляется системами управления базами данных (СУБД).
Под их руководством:
- производится добавление, определение, удаление и поиск записей;
- изменяются значения полей.
Для проведения этих операций организуются запросы. Итогом выполнения запросов будут либо изменения в таблицах, либо получение таблицы данных. При этом поддерживается принцип безопасности информации. Для реляционной БД основным языком управления является SQL.
Стадии и пример проектирования хранилища
Приступая к созданию базы, разработчик составляет для объектов манипулирования и их связей представление в терминах реляционной БД (таблицы, поля, записи). Проектирование проходит несколько стадий:
- Первая стадия — это анализ требований. Разработчик должен разрешить главные проблемы: какие элементы данных будут содержаться, как и кто должен к ним обращаться.
- В следующей стадии проектируется логическая структура БД.
- В завершающей стадии проектирования логическая структура БД трансформируется в физическую. Элементы данных определяются как табличные столбцы.
Преимущества этой модели данных состоят в том, что информация отображается в удобной для пользователя форме, а для манипуляций используется развитой математический аппарат.
Примером реляционной базы данных может послужить проект оптимизации деятельности пункта проката. Требуется автоматизировать такие процедуры: учёт клиентов; регистрацию инвентаря, выданного в прокат; отслеживание даты выдачи, сроков возврата, оплаты; получение информации по этим позициям; формирование отчёта по задолженностям. Реляционная БД может быть задана в виде трёх связанных таблиц.
Используя имеющиеся данные, следует определить отношения и объекты этих отношений. Объектами будут являться клиенты и устройства. Отношения между ними состоят в том, что каждый клиент может брать в прокат одно или несколько устройств.
Атрибутами для сопоставления объектов друг другу должны выступать ячейки с уникальным содержимым. В таблицах есть по одному полю с уникальными данными. В № 1 «Клиент» — это шифр клиента, а в № 3 «Склад» — шифр устройства. Это и будут primary keys. Каждая строка таблицы «Прокат» будет связывать два внешних ключа между собой:
- Шифр Клиента — foreign key, ссылающийся на primary key в таблице «Клиент».
- Шифр устройства — foreign key, ссылающийся на первичный ключ в таблице «Склад».
Проблемы модели
Преимущество реляционных хранилищ состоит в том, что они способны обеспечить наилучшее соотношение устойчивости, производительности, гибкости, совместимости и масштабируемости. Реляционные БД предоставляют лёгкий доступ к составляемым отчётам и обеспечивают высокую надёжность и целостность информации из-за отсутствия избыточных данных. Но сейчас, когда всё большее количество приложений работает с высокой нагрузкой, увеличивается значение фактора масштабируемости.
Реляционные БД легко масштабируются, только когда они расположены на одном сервере. Если потребуется увеличить количество серверов и разделить нагрузку между ними, то возрастёт сложность хранилищ, что значительно снизит возможность использовать их как платформу для мощных распределённых систем. Поэтому приходится применять другие типы БД, которые обладают лучшей масштабируемостью и отказываться от возможностей, предоставляемых реляционными хранилищами.
Реляционная БД — это совокупность связей, которые способны структурировать данные, что даёт возможность рационального хранения и эффективного использования информационных материалов.
Источник