Download SRBD security - hornad.fei.tuke.sk

TECHNICKÁ UNIVERZITA KOŠICE
FAKULTA ELEKTROTECHNIKY A INFORMATIKY
KATEDRA POČÍTAČOV A INFORMATIKY
Bezpečnosť SRBD (Referát)
Zadanie z predmetu Systémy riadenia bázy dát
Ročník: 4.
Skupina: ŠPZ
Šk. Rok: 2002/2003
Cvičiaci: Ing. Ján Genči
Spracoval: Ing. Viktor Belko
2
Obsah
SRBD security .................................................................................................................................. 4
THE NEED FOR SYSTEMS SECURITY .................................................................................. 4
SECURITY CONCEPTS ............................................................................................................. 4
Strong User Authentication For Accountability....................................................................... 5
Database Password-Based Authentication ............................................................................... 5
Host-Based Authentication ...................................................................................................... 5
Third Party-Based Authentication ............................................................................................ 6
Authentication Through a Middle Tier .................................................................................... 6
Mutual Authentication For Secure Distributed Computing ..................................................... 6
Privileges That Protect Data ..................................................................................................... 6
System Privileges ..................................................................................................................... 6
Object Privileges ...................................................................................................................... 7
Views To Customize Access To Information .......................................................................... 7
Stored Procedures To Customize Operations On Data ................................................................ 8
The Virtual Private Database ....................................................................................................... 9
Flexible Implementation ........................................................................................................ 10
Strong, Server-Enforced Security .......................................................................................... 10
Triggers To Customize Functionality .................................................................................... 11
Prednášky SRBD ............................................................................................................................ 12
Relačná algebra (RA) ................................................................................................................. 12
Rozširujúce operácie RA ........................................................................................................ 12
SELEKCIA - σ ....................................................................................................................... 12
PROJEKCIA - Ð .................................................................................................................... 12
SPOJENIE .............................................................................................................................. 13
Normalizácia .......................................................................................................................... 13
Transakčné spracovanie ............................................................................................................. 13
Čo je to transakcia? ................................................................................................................ 14
Vlastnosti ACID : ................................................................................................................... 14
Transakčné modely ................................................................................................................ 14
Štruktúra objektov : ................................................................................................................ 14
Štruktúra transakcie ................................................................................................................ 15
Paralelné spracovanie transakcií. ........................................................................................... 15
Problémy s paralelným spracovaním transakcii. .................................................................... 15
Sériové a usporiadateľné rozvrhy........................................................................................... 15
Konfliktová usporiadateľnosť ................................................................................................ 16
Spracovanie dotazov (Query Processing ).................................................................................. 16
Fázy spracovania dotazov ...................................................................................................... 16
Optimalizácia ......................................................................................................................... 16
Fázy optimalizačného procesu ............................................................................................... 17
Ekvivalenčné pravidlá zahrňujúce špeciálne množinové operácie ........................................ 17
Ekvivalenčné pravidlá zahrňujúce tradičné množinové operácie .......................................... 18
Univerzálne pravidlá pre optimálne transformácie ................................................................ 18
Indexácia .................................................................................................................................... 18
3
Data Dictionary – Systémový Katalóg (SK) .............................................................................. 18
Pohľady v SK ......................................................................................................................... 20
Dynamic Performance Tables ................................................................................................ 20
Fyzická organizácia ................................................................................................................... 20
Primárna organizácia súborov ................................................................................................ 21
4
SRBD security
THE NEED FOR SYSTEMS SECURITY
The opening of mission-critical systems to partners and customers over the Internet poses new
challenges to traditional notions of enterprise security. Data access must now be controlled at
a very fine level of granularity, often to the level of individual customers or users. Organizations
providing "hosting" environments seek to deploy common applications which nonetheless can
incorporate customer-specific preferences, and operate on customer-specific data. Databases
addresses these requirements by providing highly granular, server-enforced access control and
flexible privilege models. Users can be strongly authenticated, even remotely, and data is
protected in transit by network encryption. Database enforces the same strong security whether
users access data directly, or through middle tiers, such as application servers or transaction
processing (TP) monitors.
Another challenge of system security is ease of management. Organizations spend significant
time and resources managing multiple user accounts and privileges. Additionally, they often must
implement security in multiple applications accessing the same data which is duplicative and
often leads to security vulnerabilities instead of building security once, in the data server.
Security is often complex and expensive to implement. Databases addresses these needs by
offering integrated security and directory services, which enables Public Key Infrastructure
(PKI)-based single sign-on. Single Station Administration allows organizations to manage users
and their privileges centrally, with greater ease and lower cost. Flexible, granular security can be
built once in the data server, instead of in multiple applications, and business logic may be
divorced from actual privileges and data, which means that applications can be developed once,
then reused and redeployed at significant cost savings. Within the enterprise, information is
stored on physically separate computers in different locations. Therefore, it is essential that users
be able to access all information easily and consistently. Consequently, a database server must
provide the technology to hide the complexity of data access from users, allowing them to access
distributed information as if it were all stored on the same computer. For example Oracle
addresses this requirement by providing a transparent interface to all data in the system,
improving access to information and simplifying application development. Oracle addresses all
these security and functionality needs by providing complete and robust facilities for managing
data and implementing a strong, yet flexible, security policy.
This paper describes these security facilities, and how an organization can use them to enforce an
overall security policy throughout various databases.
SECURITY CONCEPTS
Basic computer security concepts require that an information system be able to identify and
controlcritical aspects such as:
Who the authorized users are (identification and authentication).
What users should have access to (object access controls).
5
What
types of operations users can perform on those objects (also part of object access control).
types of activities have occurred (e.g., the ability to maintain accountability via auditing).
Extended security concepts further address issues such as data and system integrity, reliability
and availability, further conditional access controls (such as for special business rules), and
assurance that all the above are operating properly and consistently.
What
Strong User Authentication For Accountability
The basis for system security is strong user identification and authorization; if you cannot
establish, with certainty, who a user is, then it is impossible to hold users accountable for their
actions, and to ensure that users only have access to the data they need to do their jobs, but no
more. Many databases supports a number of choices for user authentication: Database-based (by
password, or by industry-standard X.509 certificates), host-based (by the underlying operating
system), or third-party based (network authentication services, smart cards and biometric
devices).
Database Password-Based Authentication
In database password-based authentication, each user must have a username and password. To
connect to the database, a properly-authenticated operating system user must supply his database
username and password. However, password-based schemes, to be secure, must ensure that
passwords can be changed regularly, are of sufficient complexity, and are not easily guessed. For
example Informix provides built-in, robust password management facilities to enable
administrators to:
Enforce minimal password length.
Ensure password complexity (i.e., that passwords contain symbols or numbers as well as
alphabetic characters).
Disallow passwords that are easily guessed words, such as a user’s last name or
company name.
Administrators can prevent password-guessing attempts by locking accounts automatically after a number of
incorrect password entries; an administrator can also lock an account “on the fly” if he detects a security
breach. Passwords can be forced to expire over any period (every ninety days, for example) to ensure that
users change their passwords regularly. Administrators can also prevent passwords from being
reused, either permanently, or for a specified period of time. Password preferences may be assigned to an entire
enterprise, groups of users, or individual users by means of user profiles, providing complete flexibility for an
organization to implement desired security preferences.
In distributed systems, a password passing from a client to server may pose a security risk. If the
password is passed in clear text (unencrypted), any eavesdropper snooping for data can also read the password.
Host-Based Authentication
Database identification and authentication facility also allows you to specify that users should be
authenticated by operating system mechanisms, consolidating username and password
information and allowing users to enter an application without having to specify a username and
password.
6
Third Party-Based Authentication
Database security, supports multiple third-party authentication technologies, such as Kerberos,
DCE, smart cards and biometric authentication (Identix), as well as integration with Bull’s ISM
and ICL’s Access Manager. These hardware and software technologies verify a user’s identity in
a stronger way than passwords. For example, SecurID cards provide twofactor authentication —
something you have (the card) and something you know (a personal identification number (PIN)).
Many of these network authentication services also provide single signon for users. Users
authenticate themselves once to a central service (e.g., Kerberos), and may then connect to
multiple applications or databases without providing additional credentials.
Authentication Through a Middle Tier
In applications which use a heavy middle tier, such as a transaction processing monitor, it is
important to be able to preserve the identity of the client connecting to the middle tier. Yet, one
advantage of a middle tier is connection pooling, to allow multiple users to access a data server
without each of them needing a separate connection. In such environments, you need to be able to
set up (and break down) connections very quickly, without the overhead of establishing a
separate, authenticated database session for each connection.
Mutual Authentication For Secure Distributed Computing
While user authentication is important, it is equally important in distributed systems to ensure
that a number of network principals including application servers, web servers, and database
servers are who they say they are. For example, database A, attempting to connect to database
B, needs assurance that database B really is database B, just as database B needs to be sure of
database A’s identity.
For example, an AP application might need to retrieve information about employees from the HR
database in order to perform expense reporting processing. Not only could the AP and HR
databases mutually authenticate, but the HR database could grant access to only those users in AP
who need to query the employee information in order to process expense reports.
Privileges That Protect Data
A user can only perform an operation on a database object (such as a table or view) if that user
has been authorized to perform that operation. A privilege is an authorization to perform a
particular operation; without privileges, a user cannot access any information in the database. To
ensure data security, a user should only be granted those privileges that he needs to perform his
job functions. This is known as the principle of “least privilege.”
System Privileges
A system privilege authorizes a user to perform a specific operation. One example of a system
privilege is the CREATE USER privilege, which allows a user to create a database username;
another is SELECT ANY TABLE, which allows a user to query any table in the database. For
example Oracle8i provides over 100 different system privileges, such as permission to connect to
7
the database and permission to change a table's attributes. A privilege can be granted to a user
“with ADMIN option.” This allows the grantee authority to further grant and revoke privileges
from other users.
Object Privileges
An object privilege authorizes a user to perform a specific operation on a specific object. For
example, you can grant a user the ability to select from the EMP table by granting him the
SELECT privilege on that table. With this privilege, the user can query the EMP table but cannot
query any other tables in the database nor update the EMP table. You can also grant object
privileges “with GRANT option.” This allows the grantee authority to further grant the object
privilege to other users. In databases exists a varying number of object privileges per object type,
such as permission to insert into a table and permission to select from a sequence.
Views To Customize Access To Information
While privileges allow you to control which operations a user can perform on database objects,
views allow you to further limit the data that a user can access within these objects. A view is a
content- or context-dependent subset of one or more tables (or views). For example, you can
define a view that allows a manager to view only the information in the EMP table that is
relevant to employees in his own department. The view may contain only certain columns from
the base table (or tables), such as the example below, in which only the employee name and
salary information are contained in a view. Content may also be limited to a subset of the rows in
the base table, such as a view of the employee table which contains records for employees
assigned to department 20.
Similarly, you can define a view that allows payroll clerks to update payroll information on
certain days of the month only. This flexibility allows you to restrict the data that a user can see
or modify to only that data that he truly needs to access, at only the times that access is
appropriate. This allows you to enforce your unique business rules within the database. View can
be created with additional business considerations in mind. For example, views may be created
“with check option,” which enforces that inserts and updates performed through the view must be
accessible by the view query itself. This helps ensure data consistency from the user’s viewpoint.
8
Figure 1: A View Controlling Salary Access By Manager
Stored Procedures To Customize Operations On Data
It is often desirable to encapsulate business rules into stored procedures for several reasons. One
of them is that, if security is written in the front-end application, the user can bypass all the
security of the application if the user has direct privileges in the database. Another reason is that
stored procedures help enforce least privilege as well as business integrity, by ensuring that users
have the minimum privileges they need to perform their job functions, and only access data
according to well-formed business rules.
You can define a procedure so that it performs a specific business function, then grant a user the
ability to execute that procedure without granting him any access to the objects and operations
that the stored procedure uses. This prevents users from exercising privileges to perform
operations outside of the context of the pre-defined authorized procedure.
For example, the INCREASE_PAY stored procedure illustrated in Figure 2 allows managers to
increase their employees' salaries. By executing this stored procedure, managers are allowed to
increase employees' salaries by no more than 15 percent. While you could have just granted these
managers the ability to update the EMP_SALARIES view, the stored procedure allows you to
enforce your business rules within the database by restricting managers from giving their
employees increases that violate these rules. Note that the managers need not have access to the
EMP_SALARIES view in order to execute this procedure; because a stored procedure performs
an explicitly defined operation, users only need permission to execute this procedure, not
permission to access the underlying objects. This prevents users from accessing the procedure's
underlying objects outside the context of your business rules.
9
Figure 2. Stored Procedure To Update Salary
The Virtual Private Database
Giving customers and partners direct access to mission-critical systems over the Internet may
yield reduced cost, better service, and more timely information, but it also offers new challenges.
Organizations must not only keep data safe from prying eyes, but they must segregate data
appropriately, often to the level of individual customers or users. Also, many companies are
interested in providing Internet “hosting” environments, with a well-designed and well-managed
computing infrastructure, but must keep the data of each “hosted” corporation separate and
secure from each other, while allowing customizations and data access methods which best meet
their individual needs.
Within the Intranet, organizations continue to struggle with traditional access control problems,
such as the classic “application security problem”: when access control is embedded in an
application, users who have access to ad-hoc queries or reporting tools bypass the security
mechanisms of the application.
Oracle8i addresses these diverse security needs by introducing the Virtual Private Database
serverenforced, flexible, fine-grained access control, together with a secure application
context, enabling multiple customers and partners to have secure direct access to mission-critical
data. The Virtual Private Database enables, within a single database, per-user or per-customer
data access with the assurance of physical data separation. For Internet access, the Virtual Private
Database can ensure that online banking customers see only their own accounts, and that web
storefront customers see their own orders only. Web hosting companies can maintain multiple
companies’ data in the same Oracle8i database, while allowing each company to see only their
own data.
The Virtual Private Database enables fine-grained access control by associating one or more
security policies with tables or views. Direct or indirect access to a table with an attached security
policy causes the data server to consult the policy function. The policy function returns an access
10
condition known as a predicate (a WHERE clause) which the data server appends to the SQL
statements, dynamically modifying the user’s data access. For example, if an organization’s
security policy is that customers can see their own orders, a user issuing the following query:
SELECT * FROM orders;
could have her query transparently and dynamically rewritten by Oracle8i as follows:
SELECT * FROM orders WHERE cust_num = SYS_CONTEXT (‘userenv’,
‘session_user’);
Flexible Implementation
The Virtual Private Database offers flexible policy implementation, to allow customers to finetune their security policies based on their specific needs:
Attach security policies to tables or views. Many applications already use views for security
reasons, or to enforce business rules. Attaching security policies to either views or tables allows
organizations to add fine-grained access to their existing applications without completely
rewriting them.
Add security policies to only those tables or views where it is needed. For example, to
implement the policy ‘customers can see only their own orders,’ one need only add security
policies to the ORDERS and ORDER_LINES table.
Enable different policies for different types of access, (e.g., select, insert, delete, and update).
For example, you could implement a policy on the EMP table that enables users to query name
and address information for any employee, but allows them to update only their own records.
Add multiple policies per table. For example, a hosting application may allow different
companies’ HR systems to enable different access control conditions. Companies can add
additional security policies on top of the base HR application security policy (e.g., that data
access is limited by company), without affecting the base security enforcement and data
separation policies.
Strong, Server-Enforced Security
The Virtual Private Database provides the following benefits:
Lower Cost of Ownership. Organizations can reap huge cost savings by building security once,
in the data server, instead of implementing the same security in each application that accesses
data.
Eliminate the “Application Security Problem.” Users can no longer bypass security policies
embedded in applications because security policies are associated directly with data. The same
security policy is automatically enforced by the data server, no matter how a user accesses data,
whether through a report-writing tool, a query, or through an application.
Enable Applications You Could Never Build Before. In the past, organizations could not give
customers and partners direct access to their production systems, because there was no way to
secure the data. Internet hosting companies could not have data for multiple companies reside in
the same data server, because they could not separate each company’s data. Now, all these
scenarios are possible, because the Virtual Private Database gives you server-enforced,
finegrained access control with the assurance of physical data separation.
11
Triggers To Customize Functionality
Like stored procedures, database triggers are user-defined sets of PL/SQL or Java statements,
also stored in compiled form. While users explicitly execute stored procedures, database triggers
are automatically executed (or "fired") within the data server based on pre-specified events. A
trigger is defined to execute either before or after an insert, update, or delete, so that when that
operation is performed on that table, the trigger automatically fires. Four types of triggers are
available for definition on a table: BEFORE statement, BEFORE row, AFTER statement, and
AFTER row. Statement triggers are executed once regardless of the number of rows affected by
the triggering statement. Row triggers are fired once for each row affected by the triggering
statement.
The security benefits of database triggers are similar to those of stored procedures: more granular
access control and consistent rule enforcement. In addition to those benefits, database triggers
allow you to perform behind-the-scenes operations based on user activity. For example, you
could define a BEFORE UPDATE trigger on the EMP table that automatically records the
existing values in the table before a user updates them. That way, you have a record of both the
old and new values in any updated rows. You can also define multiple triggers of each type
(statement or row) on a single table, to audit several different types of operations. Triggers can be
used to apply security rules to the database.
12
Prednášky SRBD
Relačná algebra (RA)






Výber (select)
Projekcia (project)
Zjednotenie (union)
Množinový rozdiel (set difference)
Karteziánsky súčin (Cartesian product)
Premenovanie (rename)
Rozširujúce operácie RA
 Zovšeobecnená projekcia (generalized projection)
- rozširuje operáciu projekcie tak, že umožňuje použitie použitie aritmetických funkcií v
zozname atribútov projekcie
 Vonkajšie spojenie (outer join)
- vykoná operáciu spojenia a k výsledku pridá n-tice z jednej relácie, ktoré neodpovedajú
n-ticiam v druhej relácií
- využíva hodnotu null, ktorá znamená, že hodnota je neznáma alebo neexistuje
 Agregačné funkcie (aggregate functions)
- agregačný operátor berie kolekciu hodnôt a vracia jednu hodnotu ako výsledok
 AVG (priemerná hodnota)
 MIN (minimálna hodnota)
 MAX (maximálna hodnota)
 SUM (súčet hodnôt)
 COUNT (počet hodnôt)
SELEKCIA - σ
 Vyberie riadky splňujúce podmienku
 Syntax:
sselekčná podmienka(meno relácie)
 Relácia, ktorá je výsledkom selekcie, má tie isté atribúty ako relácia pôvodná
Podmienka použitá v selekcii môže byť tvaru:
Operátor porovnania je z množiny {<,=,>, ³, £ ,¹}
konštanta je z domény daného atribútu.
Podmienky môžu byť ľubovoľne spájané pomocou AND, OR, NOT
PROJEKCIA - Ð
 Zobrazí stĺpce uvedené v zozname atribútov
13
 Syntax:
Ðzoznam atribútov(meno relácie)
 Množinové operácie – zjednotenie, prienik, rozdiel relácií – dajú sa použiť na
kompatibilné relácie
SPOJENIE
 Používa sa, keď potrebujeme skombinovať súvisiace záznamy z dvoch relácií do jediného
záznamu
 Equi – Join
 Outer – Join
 Self – Join
 Natural - Join
operácia PROJEKCIA –> vyberie stĺpce
- operácia SELEKCIA –> vyberie riadky
- operácia SPOJENIE –> prevádza spojenie tabuliek cez zvolenú položku alebo skupinu položiek
Systémy s týmito zakladnými operáciami nazývame minimálne relačné
Dotazovací jazyk, ktorý umožňuje realizovať všetky operácie relačnej algebry(aj: súčin, prienik,
zjednotenie, rozdiel) – relačne úplný
Normalizácia
 Poskytuje metodiku návrhu usporiadania informácií v databáze
 Odstránenie zbytočnej duplicity uložených údajov
a pritom zachováva možnosť vhodného spájania do podoby potrebnej pre ďalšie
spracovanie
 A,B sú atribúty relácie R => B je funkčne závislý na A, pokiaľ v čase existuje ku každej
hodnote atribútu B najviac jedna hodnota atribútu A
 A, B, C sú atribúty relácie R. Ak B je funkčne závislý na A a C je funkčne závislý na B a
zároveň platí, že A funkčne nezávisí na B => C je tranzitívne závislý na A
 Prechod od nižšiej normálnej formy k vyššej prevádzame operáciou PROJEKCIA
 Prechod od vyššej normálnej formy k nižšej prevádzame operáciou SPOJENIE(JOIN)
 Pre vkladanie, rušenie a aktualizáciu je vhodná 3NF apre dotazy 1NF, preto pri formulácii
dotazu dochádza často k operácii spojenia
 Vo fáze návrhu logickej schémy relačnej bázy dat je potrebné mať všetky tabuľky v 3NF.
Neskoršie zmeny štruktúry tabuliek vedie k nutnosti zmeny databázovej aplikácie
Transakčné spracovanie
Na SRBD sú kladené dve dôležité požiadavky
• Chrániť dáta organizované pod daným SRBD
14
• Poskytnúť korektný a rýchly prístup väčšiemu počtu užívateľov
Tieto požiadavky vedú k dvom funkčným komponentám SRBD :
• komponenta riadeného súbežného spracovania (concurency control)
• komponenta zotavenia z chýb (recovery)
Čo je to transakcia?
Transakcia je istá postupnosť, alebo špecifikácia postupnosti akcií, ako sú čítanie, zápis, výpočet,
s ktorou sa narába ako s jedným celkom (napr.. niekoľko aktualizačných operácii alebo dotazov v
SQL).
Aby sa užívateľovi transakcia javila ako jedna atomicka operácia, sú nutné príkazy :
• COMMIT - po jeho vykonaní sú teda výsledky transakcie trvalé a viditeľné
• ROLLBACK - zaisťuje návrat do stavu databázy pred započatím transakcie. Jeho použitie
vyžaduje existenciu tzv.. žurnálu na nejakom stabilnom pamäťovom médiu. Žurnál
obsahuje históriu všetkých zmien databázy v istej časovej perióde.
Transakcia sa môže dostať do jedného z piatich stavov :
• aktívny (A) - ide o stav od počiatku vykonávania transakcie,
• čiastočne potvrdený (PC) - ide o stav po vykonaní poslednej operácie transakcie,
• chybný (F) - ak sa stane, že v normálnom priebehu transakcie sa nedá pokračovať,
• zrušený (AB) - nastane po skončení operácie ROLLBACK, tj. uvedenie databázy do stavu
pred transakciou,
• potvrdený (C) - nastane po úspešnom zakončení, tj. Po potvrdení operácie COMMIT.
Vlastnosti ACID :
•
•
•
•
atomicita - transakcia sa tvári ako jeden celok, musí sa buď vykonať celá alebo vôbec nie,
konzistencia - transakcia transformuje databázu z jedného konzistentného stavu do iného
stavu,
nezávislosť - transakcie sú nezávislé, tj. Dielčie efekty transakcie niesu viditeľné inými
transakciami,
trvanlivosť - efekty úspešne ukončenej (potvrdenej) transakcie sú uložené do databázy
Transakčné modely
Transakčný model je charakterizovaný štruktúrou transakcie a štruktúrou objektov, na ktorých
transakcia operuje. Transakčné modely špecifikujú (okrem iného) užívateľské rozhranie k
transakcii ako takej.
Štruktúra objektov :
•
•
jednoduché objekty - podstatné na tomto druhu objektov je,že sa neberie do úvahy ich
sémantika.
abstraktný dátový typ (ADT) - použitie ADT znamená použitie abstraktných operácií
zviazaných s objektmi.
15
•
•
zložité objekty - objektovo-orientované SRBD predstavujú objekty so štruktúrou, ktorých
komponentou môže byť opäť objekt.
aktívne (a pasívne) objekty - patria tzv. aktívnym databázam.
Štruktúra transakcie
•
•
•
•
ploché transakcie - tieto transakcie majú jednoduchý bod štartu a jednoduchý bod
ukončenia.
uzavreté hniezdené transakcie - zahrňujú ďalšie transakcie so svojimi bodmi štartu a
ukončenia. Potvrdzovanie podtransakcií sa deje zdola-nahor.
otvorené hniezdené transakcie - u týchto transakcií vzniká požiadavka na atomicitu
koreňovej transakcie. Čiastočné výsledky môžu byť viditeľné mimo transakciu ktorá ju
objednáva,
pracovné toky - sú modelované pomocou aktivít, úloh, z hľadiska transakčného
spracovania pomocou uzavretých transakcií.
Paralelné spracovanie transakcií.
Transakcie môžu byť v užívateľských aplikačných programoch vykonávané paralelne. Je zrejme
a z hľadiska využitia zdrojov žiaduce, že postupnosti transakcii môžu byť spracúvané paralelne
rôznymi spôsobmi. Predpokladajme transakcie T1 a T2 dané postupnosťami {T11,...,T1n}, resp.
{T21,...,T2m}. Stanovené poradie vykonávania akcií viacerých transakcií v čase nazývame
rozvrh.
Problémy s paralelným spracovaním transakcii.
Prekrývanie operácií transakcií nemôže byť ľubovoľné.
 strata aktualizácie
 dočasná aktualizácia (pri chybe systému)
 nekorektné použitie agregačnej funkcie
 neopakovateľné čítanie
Transakcia T1 používajúca daný kurzor sa snaží znovu prečítať riadok, ktorý už raz čítala
pred tým, ten však už obsahuje iné hodnoty (alebo neexistuje) vďaka aktualizácii
transakcie T2 , ktorá prebieha paralelne
 fantóm
Transakcia T prečíta množinu riadkov (jeden príkaz SELECT) a spracováva ich. Medzi
tým niektoré z týchto riadkov zmení transakcia T’ (DELETE alebo INSERT). Keď
použije T ten istý príkaz, obdrží inú množinu riadkov.
Sériové a usporiadateľné rozvrhy
Dôležitými pojmami pre paralelné spracovanie sú sériovosť či usporiadateľnosť. Sériové
rozvrhy zachovávajú operácie každej transakcie pohromade. Pre N transakcií teda existuje N!
rôznych sériových rozvrhov. Pre získanie korektného výsledku však môžeme použiť i rozvrh, kde
sa operácie navzájom prekrývajú. Prirodzenou požiadavkou na korektnosť je, aby efekt
paralelného spracovania transakcií bol ten istý, ako keby boli transakcie vykonané v nejakom
16
sériovom rozvrhu. Ak predpokladáme, že každá transakcia je korektný program, mal by viesť
výsledok sériového spracovania ku konzistentnému stavu. O SZT, ktorý zaručuje túto vlastnosť
sa hovorí, že zaručuje usporiadateľnosť.Aby sme mohli pre nejaký rozvrh určiť jeho
korektnosť, stačí aby sme ukázali, že je v nejakom zmysle ekvivalentný nejakému sériovému
rozvrhu.

ekvivalencia vzhľadom ku konfliktom
Ak máme rozvrhy S1 a S2 pre množinu transakcií T = {T1,...,Tn}, potom S1 s S2 sú
ekvivalentné (vzhľadom ku konfliktom), keď sú v oboch rozvrhoch všetky dvojice
konfliktných operácií vykonávané v rovnakom (časovom) poradí.

pohľadová ekvivalencia
Ak máme rozvrhy S1 a S2 pre množinu transakcií T = {T1,...,Tn}, potom S1 s S2 sú
pohľadovo ekvivalentné, keď sú splnené tri podmienky:
• Ak v jednom rozvrhu je počiatočná hodnota A čítaná v transakcii Ti, potom to isté
musí platiť i v druhom rozvrhu.
• Ak sa v jednom rozvrhu vyskytuje READ(A) v transakcii Ti a táto hodnota vznikla
z WRITE(A) v transakcií Tj, potom to isté musí byť zachované i v druhom rozvrh.
• Ak sa v jednom rozvrhu zapisuje konečná hodnota A v transakcii Ti, potom to isté
musí platiť i v druhom rozvrhu.
Konfliktová usporiadateľnosť
Zostrojíme precedenčný graf rozvrhu, ktorého uzly sú transakcie a hrany (Ti, Tj) sú definované
splnením jednej z nasledujúcich podmienok:
• Ti volá WRITE(A), pred tým ako Ti volá READ(A)
• Ti volá READ(A), pred tým ako Ti volá WRITE(A)
• Ti volá WRITE(A), pred tým ako Ti volá WRITE(A)
pre nejaký atribút A z obidvoch transakcií.
Spracovanie dotazov (Query Processing )
Fázy spracovania dotazov




Fáza dekompozície: snímanie , syntaktická analýza a sémantická kontrola, normalizácia,
simplifikácia, reštrukturalizácia, verifikácia
Fáza optimalizácia
Fáza generovania cieľového kódu
Fáza realizácie
Optimalizácia
•
•
Heuristická (Heuristics): preusporiadava dotazy vo vykonávacom pláne
Podľa výpočtu cenových nákladov (cost estimation): založená na výpočte
pravdepodobnosti cenového ohodnotenia jednotlivých stratégií
17
Fázy optimalizačného procesu
1. Prevod dotazu do interného formátu
 jazyky pre manipuláciu s dátami (DML languages) sú vhodné pre ľudskú
interpretáciu, ale nie sú vhodné pre počítačové spracovanie /málo matematiky /
 jazyk používaný v tejto internej reprezentácii musí byť prinajmenšom taký
výrazový ako jazyk v ktorom je písaný pôvodný dotaz
 predpokladáme, že relačná algebra je prostriedkom interného formátu, pomocou
ktorého môžeme celý proces optimalizácie analyzovať detailnejšie
2. Prevod internej reprezentácie na kánonický tvar
 v tejto fáze je nad dotazom vykonané množstvo transformácií
 tieto transformácie nesmú zmeniť sémantiku dotazu, jednoducho hľadajú
ekvivalentné dotazy, ktorých realizácia je efektívnejšia a výkonnejšia ako dotaz
pôvodný
 tieto transformácie sa zvyčajne nazývajú Ekvivalenčné pravidlá pre operácie
relačnej algebry
3. Výber vhodného kandidáta pre spracovanie procedúr
 Kánonický tvar zvyčajne môže realizovaný rôznymi sôsobmi v závislosti podľa
toho ako sú informácie v systéme uložené
 nízkoúrovňové špeciálne množinové operácie (selekcia, projekcia, join...) sú
asociované sadou preddefinovaných implementačných procedúr.
 tieto procedúry sa obmieňajú podľa typu operácie a atribútov, ktoré sú obsahujú.
 každá procedúra je popísaná funkciou pomocou ktorej je možné vypočítať náklady
spojené s činnosťou každej operácie (rôzne procedúry môžu byť vykonávané
podľa rôznych cenových nákladov)
4. Generovanie vykonávacích plánov a výber toho najlacnejšieho z nich
 pretože, nad každým dotazom je zvyčajne vykonané množstvo operácií, a každá
operácia môže byť implementovaná rôznymi spôsobmi, je tam aj množstvo
možných kombinácií týchto operácií, ktoré dávajú konečný výsledok.
 všeobecne povedané, v tejto fáze tam bude príliš veľa možných plánov
asociovaných s komplexným dotazom no nieje možné brať do úvahy všetky
z nich.
 na základe vnútorných kritérií, len niektoré z celkových cien plánov pre riešenie
dotazu sú zhodnotené. Optimalizátor si potom vyberie ten plán ktorý má najnižšiu
cenu.
Ekvivalenčné pravidlá zahrňujúce špeciálne množinové operácie
1. Kaskáda/Kompozícia selekcií
2. Komutatívnosť selekcií
3. Kaskáda projekcií
4. Kombinácia selekcie, karteziánskeho súčinu a Theta Join-u
5. Komutatívnosť selekcie a projekcie
18
6. Komutatívnosť Theta-Join operácií
7. Asociatívnosť natural join operácií
8. Komutatívnosť projekcie a Theta-Join-u
Ekvivalenčné pravidlá zahrňujúce tradičné množinové operácie
1. Asociatívnosť operácií karteziánsky súčin, prienik, zjednotenie a rozdiel
2. Komutatívnosť operácií karteziánsky súčin, prienik, zjednotenie
3. Komutatívnosť selekcie a operácií prienik, zjednotenie alebo rozdiel
4. Komutatívnosť projekcie a zjednotenia
Univerzálne pravidlá pre optimálne transformácie
1. Skoré uskutočnenie selekcií a projekcií
2. Kombinácia karteziánskeho súčinu s následnou selekciou na operácii Theta-Join
3. Použitie asociativity binárnych operácií na preusporiadanie listových uzlov tak, aby listové
uzly s najviac obmedzujúcimi selekciami boli realizované skôr
4. Jednoduché podvýrazy počítať iba raz
Indexácia
Rýchly a efektívny prístup k položkámsúboru na základe niektorého z polí položky
Ukladanie indexov:
 sekvenčný súbor (jednoúrovňové indexy)
 stromy (viacúrovňové indexy, B-stromy)
Vlastnosti indexov:
 clustered verzus unclustered
 dense verzus sparse
 primary and secondary
 logical and physical
Uchovávanie indexov:
 prehľadávacie stromy
 B-stromy
Data Dictionary – Systémový Katalóg (SK)
Jedna z najdôležitejších častí databázy je systémový katalóg. Je to množina (skupina) read-only
tabuliek, ktoré poskytujú informácie o všetkých databázových objektoch
19
Systémový Katalóg obsahuje:
 Definície všetkých objektov v DB (tabuľky, pohľady, indexy, clustre, synonymá,
sekvencie, procedúry, funkcie, triggre atď.)
 Koľko miesta je alokovaného a práve používaného objektmi DB
 Default hodnoty pre stĺpce
 Informácie o referenčnej integrite
 Mená DB používateľov
 Práva a role, ktoré boli používateľovi priradené
 Evidenčné informácie kto a kedy pristúpil do DB, ktoré dáta boli zmenené a pod.
 Iné všeobecné informácie o DB
Štruktúra Systémového Katalógu
 Základné tabuľky (Base tables)
– Udržiavajú informácie o prepojení DB
– Zápis je možný len databázou
– Priamy prístup používateľov k týmto tabuľkám je len výnimočný
– Dáta v týchto tabuľkách sú kryptované
 Používateľsky prístupné pohľady
(User-accesible views)
– Sumarizujú a zobrazujú informácie uložené v Base Tabuľkách Systémového
Katalógu
– Dekódujú dáta kryptované v Base Tabuľkách na používateľovi užitočnejšie
informácie
Ako sa používa Sys. Kat.
 DB pristupuje do SK aby našla informácie o používateľoch, DB objektoch a štruktúrach
uloženia
 DB modifikuje SK zakaždým spustením DDL príkazu
 Každý používateľ môže používať SK ako read-only referenciu pre získanie informácií o
DB
Ako DB používa SK
 Public(Verejné) synonymá pre pohľady(Views) SK
– DB vytvára veľa pohľadov SK tak aby ich používatelia mohli vhodne používať
– Názvy DB objektov by si používatelia nemali voliť tie isté ako sú synonymá v SK
 Kešovanie (Caching) SK
– Väčšina dát sa kešuje do SGA (cache SK)
– Všetky často pristupované informácie zo SK sú uložené v pamäti (používa sa LRU
algoritmus)
 Iné programy a SK
– Iné programy mimo DB môžu používať pohľady SK
– Je lepšie používať Public synonymá ako priamo tabuľky SK
 Pridávanie nových objektov od SK
– Je možné pridávať nové tabuľky alebo pohľady do SK
– Pridávať môže len používateľ SYSTEM alebo použ. Tretej strany
– Nikdy nevytvárajte tabuľky pre používateľa SYS!!!
 Mazanie objektov SK
20
–
–
Všetky operácie spracováva DB
Žiadne dáta a objekty patriace SK nesmú byť menené alebo mazané hocakým
používateľom
Ako používatelia používajú SK
 Pohľady SK slúžia všetkým používateľom
 SK je stále k dispozícii ak je DB on-line
 SK pozostáva zo súboru(množiny) pohľadov
– Pohľady sa od seba líšia prefixom:
 USER – pohľady používateľa (to čo vlastní 1 user)
 ALL – rozšírený používateľský pohľad
 DBA – pohľad DB administrátora
– Stĺpce v pohľadoch sú identické okrem:
 Pohľady z prefixom USER vylučujú stĺpce OWNER (vlastník)
 Niektoré pohľady DBA majú dodatočné stĺpce vhodné iba pre DB
administrátorov
Pohľady v SK
 Pohľady s prefixom USER
– Referujú do používateľovho prostredia
– Zobrazujú len riadky vzťahujúce sa k používateľovi
– Obsahujú stĺpce totožné s inými pohľadmi okrem stĺpca OWNER
– Vrátia podmnožinu informácií pohľadov s prefixom ALL
– Môžu obsahovať zostručnené informácie PUBLIC synonymá
 Pohľady s prefixom ALL
– Referujú do celkového používateľského prostredia
– Vracajú informácie o objektoch ku ktorým má používateľ prístup
 Pohľady s prefixom DBA
– Zobrazujú globálny pohľad na DB
– Prístupné len pre DB Administrátorov
Dynamic Performance Tables
 Virtuálne tabuľky zaznamenávajúce aktivitu DB
– Nie sú to skutočné tabuľky
– Sú na nich vytvorené pohľady (fixed views)
 SYS vlastní dynamic performance tables
– V_$ -> prefix pre dynamic performance tables
– V$ -> prefix pre synonymá
Fyzická organizácia
21
Primárna organizácia súborov
Báza dát je množina údajov, ktoré logicky súvisia a majú určitú štruktúru. Pri štruktúre dát
rozlišujeme dva pohľady na dáta:
1. fyzická štruktúra – jedná sa o štruktúru uloženia na pamäťovom médiu. V tomto prípade
hovoríme o primárnej organizácii dát. V architektúre SRBD je prezentovaný internou
schémou.
2. logický pohľad na údaje – logická štruktúra resp. organizácia údajov – je to ľudský
pohľad na dáta, ich vlastnosti a vzťahy. V trojúrovňovej architektúre SRBD je
reprezentovaný konceptuálnou schémou.
1. Fyzická štruktúra
Dáta umiestnené v databáze musia byť fyzicky uložené na nejakom pamäťovom médiu. Tieto
dáta SRBD spracováva. Sú dve hlavné kategórie pamäťových zariadení.
1. Primárna pamäť. Patrí sem hlavná pamäť (resp. operačná pamäť), rýchle cache pamäte.
Dáta umiestnené v týchto pamätiach sú spracovávané priamo procesorom, umožňujú
rýchly prístup k dátam, ale majú malú kapacitu.
2. Sekundárna pamäť. Patria sem magnetické disky, optické disky, magnetické pásky. Majú
väčšiu kapacitu, sú lacnejšie a pomalšie ako primárne pamäte. Dáta umiestnené v týchto
pamätiach nemôžu byť spracovávané priamo procesorom, najprv musia byť umiestnené
do primárnej pamäti.
Najčastejšou sekundárnou pamäťou pre databázy je magnetický disk. Má veľkú kapacitu, je
pomerne stálou pamäťou oproti primárnym pamätiam.
Veľmi dôležitou charakteristikou je umiestnenie veľkého množstva dát na disku, tzv. kapacita
pamäťového média. Techniky uloženia dát na sekundárnej pamäti resp. na disku sú dôležité pre
databázových návrhárov, databázového administrátora ako aj pre implementáciu SRBD.
Disky sú zariadenia z náhodným prístupom. Hardware-ová adresa bloku je kombináciou čísla
strany disku, čísla stopy na príslušnej strane a čísla bloku na príslušnej stope. Vstupno-výstupné
operácie sa realizujú cez vyrovnávaciu pamäť. Základnou prenosovou jednotkou je blok, ktorého
veľkosť je definovaná pri formátovaní disku.
Celkový čas na lokalizáciu dát a prenos z určitého bloku je daný súčtom vyhľadávacieho času
bloku, rotačným oneskorením čítacieho zariadenia a časom prenosu bloku.
Požiadavka spracovania viacerých blokov je riešená paralelným spracovaním, a to buď
interleavingom (striedaním) alebo simultánne.
Interleaving je charakteristický pre jednoprocesorové systémy riadiace paralelné procesy.
Simultánne spracovanie je možné v prípade viacprocesorovej jednotky, alebo ak existuje
nezávislý vstupno-výstupný procesor.
2. Logická štruktúra
Organizačné jednotky logickej štruktúry dát sú nasledovné:
Položka (prvok, field, item) – najmenšia organizačná jednotka štruktúry dát, ktorá neobsahuje
žiadne iné položky. Je charakterizovaná identifikátorom (menom) a typom.
Skupina – množina položiek s jedným identifikátorom, prostredníctvom ktorého môžeme robiť
ako s jedným celkom. Patrí sem aj opakujúca sa skupina. Napr. dátum sa skladá – deň, mesiac,
rok; dieťa – meno, priezvisko – pre zamestnanca sa opakuje n-krát.
22
Veta (záznam, record, riadok tabuľky, tuple, entica) – zložená z položiek alebo skupín dát, ktoré
sú v nejakom vzťahu s určitým objektom. Veta musí dávať sémantický význam.
Súbor (file, table) – množina výskytov štruktúrne rovnorodých viet (viet jedného typu).
Báza dát – komplex súborov a vzťahov medzi vetami súborov, vetami skupín a položkami
Dáta sú zvyčajne umiestnené v záznamoch. Každý záznam pozostáva z množiny príbuzných
dátových hodnôt alebo položiek, pričom každá hodnota je jeden alebo viac bytov a korešponduje
s príslušným poľom v zázname. Záznamy zvyčajne popisujú entity a ich atribúty.
Množina názvov polí a ich zodpovedajúce dátové typy vytvárajú definíciu typu resp. formátu
záznamu. Dátový typ spojený s každým poľom špecifikuje typ hodnôt pre príslušné pole.
Veľkosť jednotlivých typov závisí od implementácie.
Špeciálne typy BLOB, CLOB ( Binary Large OBjects, Char Large Objects ) sú vhodné pre veľké
neštruktúrované objekty, reprezentujúce obrázky, voľný text. Dáta sú umiestnené na iných
blokoch ako sú záznamy. V záznamoch sa nachádza len smerník na príslušnú oblasť.