761:, in which the database provides each reading transaction the prior, unmodified version of data that is being modified by another active transaction. This allows readers to operate without acquiring locks, i.e., writing transactions do not block reading transactions, and readers do not block writers. Going back to the example, when user A's transaction requests data that user B is modifying, the database provides A with the version of that data that existed when user B started his transaction. User A gets a consistent view of the database even if other users are changing data. One implementation, namely
240:
each and every situation, including power failures, errors, and crashes. A guarantee of atomicity prevents updates to the database from occurring only partially, which can cause greater problems than rejecting the whole series outright. As a consequence, the transaction cannot be observed to be in progress by another database client. At one moment in time, it has not yet happened, and at the next, it has already occurred in whole (or nothing happened if the transaction was canceled in progress).
485:
operations "indivisible". A guarantee of atomicity prevents updates to the database from occurring only partially, which can cause greater problems than rejecting the whole series outright. In other words, atomicity means indivisibility and irreducibility. Alternatively, we may say that a logical transaction may be composed of several physical transactions. Unless and until all component physical transactions are executed, the logical transaction will not have occurred.
1662:
1672:
350:
43:
546:, which is inconsistent with the rules of the database. The entire transaction must be canceled and the affected rows rolled back to their pre-transaction state. If there had been other constraints, triggers, or cascades, every single change operation would have been checked in the same way as above before the transaction was committed. Similar issues may arise with other constraints. We may have required the data types of both
1682:
750:
including data that is read but not modified. Non-trivial transactions typically require a large number of locks, resulting in substantial overhead as well as blocking other transactions. For example, if user A is running a transaction that has to read a row of data that user B wants to modify, user B must wait until user A's transaction completes.
558:, the transaction will be canceled, or the system may give rise to an alert in the form of a trigger (if/when the trigger has been written to this effect). Another example would be integrity constraints, which would not allow us to delete a row in one table whose primary key is referred to by at least one
749:
Many databases rely upon locking to provide ACID capabilities. Locking means that the transaction marks the data that it accesses so that the DBMS knows not to allow other transactions to modify it until the first transaction succeeds or fails. The lock must always be acquired before processing data,
799:
to ensure that each participant in the transaction agrees on whether the transaction should be committed or not. Briefly, in the first phase, one node (the coordinator) interrogates the other nodes (the participants), and only when all reply that they are prepared does the coordinator, in the second
740:
must be acquired on all information to be updated, and depending on the level of isolation, possibly on all data that may be read as well. In write ahead logging, durability is guaranteed by writing the prospective change to a persistent log before changing the database. That allows the database to
488:
An example of an atomic transaction is a monetary transfer from bank account A to account B. It consists of two operations, withdrawing the money from account A and depositing it to account B. We would not want to see the amount removed from account A before we are sure it has also been transferred
787:, where no single node is responsible for all data affecting a transaction, presents additional complications. Network connections might fail, or one node might successfully complete its part of the transaction and then be required to roll back its changes because of a failure on another node. The
239:
guarantees that each transaction is treated as a single "unit", which either succeeds completely or fails completely: if any of the statements constituting a transaction fails to complete, the entire transaction fails and the database is left unchanged. An atomic system must guarantee atomicity in
484:
Atomicity is the guarantee that series of database operations in an atomic transaction will either all occur (a successful operation), or none will occur (an unsuccessful operation). The series of operations cannot be separated with only some of them being executed, which makes the series of
727:
Processing a transaction often requires a sequence of operations that is subject to failure for a number of reasons. For instance, the system may have no room left on its disk drives, or it may have used up its allocated CPU time. There are two popular families of techniques:
194:
who named atomicity, consistency, and durability, but not isolation, when characterizing the transaction concept. These four properties are the major guarantees of the transaction paradigm, which has influenced many aspects of development in
1000:
An operation during which a processor can simultaneously read a location and write it in the same bus operation. This prevents any other processor or I/O device from writing or reading memory until the operation is
714:
Consider a transaction that transfers 10 from A to B. First, it removes 10 from A, then it adds 10 to B. At this point, the user is told the transaction was a success. However, the changes are still queued in the
570:
To demonstrate isolation, we assume two transactions execute at the same time, each attempting to modify the same data. One of the two must wait until the other completes in order to maintain isolation.
698:, because two transactions attempted to write to the same data field. In a typical system, the problem would be resolved by reverting to the last known good state, canceling the failed transaction T
307:
ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially. Isolation is the main goal of
741:
return to a consistent state in the event of a crash. In shadowing, updates are applied to a partial copy of the database, and the new copy is activated when the transaction commits.
175:. For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction.
17:
501:
Consistency is a very general term, which demands that the data must meet all validation rules. In the previous example, the validation is a requirement that
1272:
171:, a sequence of database operations that satisfies the ACID properties (which can be perceived as a single logical operation on the data) is called a
1255:
1267:
1111:
328:
guarantees that once a transaction has been committed, it will remain committed even in the case of a system failure (e.g., power outage or
1179:
719:
waiting to be committed to disk. Power fails and the changes are lost, but the user assumes (understandably) that the changes persist.
410:
The following examples further illustrate the ACID properties. In these examples, the database table has two columns, A and B. An
273:, and any combination thereof. This prevents database corruption by an illegal transaction. An example of a database invariant is
1027:
311:; depending on the isolation level used, the effects of an incomplete transaction might not be visible to other transactions.
1189:
1151:
1062:
1706:
1665:
1338:
1227:
1086:
968:
512:. All validation rules must be checked to ensure consistency. Assume that a transaction attempts to subtract 10 from
397:
203:
126:
379:
758:
107:
1711:
1685:
1391:
845:
257:
ensures that a transaction can only bring the database from one consistent state to another, preserving database
79:
1642:
1289:
375:
254:
249:
152:
64:
1581:
944:
907:
325:
320:
191:
160:
489:
into account B. Performing these operations in an atomic transaction ensures that the database remains in a
86:
1716:
830:
304:
294:
258:
236:
223:
156:
148:
1576:
1607:
1326:
167:
intended to guarantee data validity despite errors, power failures, and other mishaps. In the context of
1530:
1520:
1296:
911:
196:
93:
1617:
1350:
840:
788:
695:
360:
1140:
Silberschatz, Abraham; Korth, Henry F.; Sudarshan, S. (2011). "Advanced
Application Development".
1566:
1220:
1119:
796:
780:
774:
737:
364:
75:
53:
1647:
1602:
1279:
1195:
1622:
1376:
411:
371:
274:
262:
214:
The characteristics of these four properties as defined by Reuter and Härder are as follows:
60:
31:
1675:
1612:
1494:
1464:
1333:
1284:
825:
809:
784:
300:
261:: any data written to the database must be valid according to all defined rules, including
228:
164:
493:, that is, money is neither debited nor credited if either of those two operations fails.
8:
1632:
1525:
1510:
1437:
1262:
820:
729:
333:
308:
984:
1627:
1571:
1540:
1489:
1381:
1321:
1213:
953:
889:
835:
762:
266:
206:
supported ACID transactions as early as 1973 (although the acronym was created later).
1447:
1301:
1185:
1157:
1147:
1068:
1058:
1012:
C. J. Date, "SQL and
Relational Theory: How to Write Accurate SQL Code 2nd edition",
964:
893:
792:
751:
535:
successfully, atomicity will be achieved. However, a validation check will show that
332:). This usually means that completed transactions (or their effects) are recorded in
329:
1637:
1484:
1474:
1442:
922:
881:
490:
270:
140:
100:
1545:
1515:
1469:
1250:
960:
1597:
1535:
1479:
1452:
1345:
1306:
1175:
948:
869:
626:
If these operations are performed in order, isolation is maintained, although T
414:
requires that the value in A and the value in B must sum to 100. The following
303:(e.g., multiple transactions reading and writing to a table at the same time).
179:
1205:
1051:
Silberschatz, Abraham; Korth, Henry F.; Sudarshan, S. (2011). "Transactions".
865:
183:
1700:
1416:
1401:
1161:
1072:
733:
1141:
1052:
690:
has already modified A; it cannot be restored to the value it had before T
520:. Because consistency is checked after each transaction, it is known that
1406:
1386:
815:
716:
559:
282:
645:
By interleaving the transactions, the actual order of actions might be:
1550:
1459:
1421:
1396:
919:
Proceedings of the 7th
International Conference on Very Large Databases
278:
232:
885:
349:
42:
1411:
1366:
1236:
168:
554:
to be integers. If we were then to enter, say, the value 13.5 for
531:
before the transaction begins. If the transaction removes 10 from
872:(1983). "Principles of transaction-oriented database recovery".
1316:
1311:
955:
Distributed
Transaction Processing: Concepts and Techniques
1139:
1050:
415:
694:
without leaving an invalid database. This is known as a
1146:(6th ed.). New York: McGraw-Hill. p. 1042.
1057:(6th ed.). New York: McGraw-Hill. p. 631.
67:. Unsourced material may be challenged and removed.
952:
912:"The Transaction Concept: Virtues and Limitations"
1174:
1698:
682:fails while modifying B in Step 4. By the time T
634:fails halfway through. The database eliminates T
1235:
754:is often applied to guarantee full isolation.
744:
702:, and restarting the interrupted transaction T
1221:
864:
18:Atomicity, consistency, isolation, durability
1184:(2nd ed.). Morgan Kaufmann (Elsevier).
1025:
768:
378:. Unsourced material may be challenged and
1228:
1214:
943:
27:Set of properties of database transactions
1028:"Isolation Levels in the Database Engine"
398:Learn how and when to remove this message
127:Learn how and when to remove this message
1168:
418:code creates a table as described above:
1006:
14:
1699:
1178:; Newcomer, Eric (2009). "Chapter 8".
496:
1209:
1109:
709:
630:must wait. Consider what happens if T
1181:Principles of Transaction Processing
906:
565:
376:adding citations to reliable sources
343:
65:adding citations to reliable sources
36:
1681:
24:
1112:"Atomic File Transactions, Part 1"
800:phase, formalize the transaction.
779:Guaranteeing ACID properties in a
765:, relaxes the isolation property.
593:Combined, there are four actions:
209:
202:According to Gray and Reuter, the
25:
1728:
722:
678:Again, consider what happens if T
204:IBM Information Management System
1680:
1670:
1661:
1660:
759:multiversion concurrency control
348:
299:Transactions are often executed
41:
1671:
1133:
231:are often composed of multiple
52:needs additional citations for
1103:
1079:
1044:
1019:
977:
937:
900:
858:
479:
250:Consistency (database systems)
243:
190:, building on earlier work by
13:
1:
991:. Webopedia. 25 November 2003
851:
757:An alternative to locking is
321:Durability (database systems)
314:
831:Open Systems Interconnection
295:Isolation (database systems)
288:
224:Atomicity (database systems)
217:
163:) is a set of properties of
7:
1707:Database management systems
1237:Database management systems
1026:Archiveddocs (2012-10-04).
803:
745:Locking vs. multiversioning
574:Consider two transactions:
339:
10:
1733:
1643:Object–relational database
772:
318:
292:
247:
221:
29:
1656:
1618:Federated database system
1590:
1559:
1503:
1430:
1359:
1351:Blockchain-based database
1243:
921:. Cupertino, California:
841:Two-phase commit protocol
795:) provides atomicity for
791:(not to be confused with
789:two-phase commit protocol
589:transfers 20 from B to A.
582:transfers 10 from A to B.
1143:Database system concepts
1054:Database system concepts
797:distributed transactions
769:Distributed transactions
420:
781:distributed transaction
775:Distributed transaction
277:, which guarantees the
1712:Transaction processing
1648:Transaction processing
1603:Database normalization
1546:Query rewriting system
696:write-write contention
642:sees only valid data.
1623:Referential integrity
1110:Amsterdam, Jonathan.
874:ACM Computing Surveys
706:from the good state.
275:referential integrity
165:database transactions
32:Acid (disambiguation)
1613:Distributed database
1176:Bernstein, Philip A.
1014:O'reilly Media, Inc.
826:Java Transaction API
810:Eventual consistency
785:distributed database
660:subtracts 20 from B.
653:subtracts 10 from A.
615:subtracts 20 from B.
601:subtracts 10 from A.
412:integrity constraint
372:improve this section
61:improve this article
30:For other uses, see
1717:Concurrency control
1633:Relational calculus
1511:Concurrency control
1032:learn.microsoft.com
821:Concurrency control
730:write-ahead logging
497:Consistency failure
334:non-volatile memory
309:concurrency control
186:coined the acronym
1628:Relational algebra
1572:Query optimization
1377:Armstrong's axioms
985:"Atomic operation"
925:. pp. 144–154
910:(September 1981).
836:Transactional NTFS
763:snapshot isolation
710:Durability failure
1694:
1693:
1302:Wide-column store
1297:Document-oriented
1191:978-1-55860-623-4
1153:978-0-07-352332-3
1064:978-0-07-352332-3
793:two-phase locking
752:Two-phase locking
736:. In both cases,
638:'s effects, and T
566:Isolation failure
562:in other tables.
516:without altering
408:
407:
400:
137:
136:
129:
111:
16:(Redirected from
1724:
1684:
1683:
1674:
1673:
1664:
1663:
1638:Relational model
1608:Database storage
1485:Stored procedure
1230:
1223:
1216:
1207:
1206:
1200:
1199:
1194:. Archived from
1172:
1166:
1165:
1137:
1131:
1130:
1128:
1127:
1118:. Archived from
1107:
1101:
1100:
1098:
1097:
1083:
1077:
1076:
1048:
1042:
1041:
1039:
1038:
1023:
1017:
1010:
1004:
1003:
997:
996:
981:
975:
974:
958:
941:
935:
934:
932:
930:
923:Tandem Computers
916:
904:
898:
897:
862:
545:
530:
511:
491:consistent state
475:
472:
469:
466:
463:
460:
457:
454:
451:
448:
445:
442:
439:
436:
433:
430:
427:
424:
403:
396:
392:
389:
383:
352:
344:
197:database systems
141:computer science
132:
125:
121:
118:
112:
110:
69:
45:
37:
21:
1732:
1731:
1727:
1726:
1725:
1723:
1722:
1721:
1697:
1696:
1695:
1690:
1652:
1598:Database models
1586:
1555:
1541:Query optimizer
1516:Data dictionary
1499:
1470:Transaction log
1426:
1382:Codd's 12 rules
1355:
1285:Column-oriented
1251:Object-oriented
1239:
1234:
1204:
1203:
1192:
1173:
1169:
1154:
1138:
1134:
1125:
1123:
1108:
1104:
1095:
1093:
1091:docs.oracle.com
1085:
1084:
1080:
1065:
1049:
1045:
1036:
1034:
1024:
1020:
1016:, 2012, p. 180.
1011:
1007:
994:
992:
983:
982:
978:
971:
961:Morgan Kaufmann
949:Reuter, Andreas
942:
938:
928:
926:
914:
905:
901:
886:10.1145/289.291
863:
859:
854:
806:
777:
771:
747:
725:
712:
705:
701:
693:
689:
685:
681:
673:
666:
659:
652:
641:
637:
633:
629:
621:
614:
607:
600:
588:
581:
568:
557:
553:
549:
543:
539:
536:
534:
528:
524:
521:
519:
515:
509:
505:
502:
499:
482:
477:
476:
473:
470:
467:
464:
461:
458:
455:
452:
449:
446:
443:
440:
437:
434:
431:
428:
425:
422:
404:
393:
387:
384:
369:
353:
342:
323:
317:
297:
291:
252:
246:
226:
220:
212:
210:Characteristics
133:
122:
116:
113:
70:
68:
58:
46:
35:
28:
23:
22:
15:
12:
11:
5:
1730:
1720:
1719:
1714:
1709:
1692:
1691:
1689:
1688:
1678:
1668:
1657:
1654:
1653:
1651:
1650:
1645:
1640:
1635:
1630:
1625:
1620:
1615:
1610:
1605:
1600:
1594:
1592:
1591:Related topics
1588:
1587:
1585:
1584:
1579:
1574:
1569:
1567:Administration
1563:
1561:
1557:
1556:
1554:
1553:
1548:
1543:
1538:
1536:Query language
1533:
1528:
1523:
1518:
1513:
1507:
1505:
1501:
1500:
1498:
1497:
1492:
1487:
1482:
1477:
1472:
1467:
1462:
1457:
1456:
1455:
1450:
1445:
1434:
1432:
1428:
1427:
1425:
1424:
1419:
1414:
1409:
1404:
1399:
1394:
1389:
1384:
1379:
1374:
1369:
1363:
1361:
1357:
1356:
1354:
1353:
1348:
1343:
1342:
1341:
1331:
1330:
1329:
1319:
1314:
1309:
1304:
1299:
1294:
1293:
1292:
1282:
1277:
1276:
1275:
1270:
1260:
1259:
1258:
1247:
1245:
1241:
1240:
1233:
1232:
1225:
1218:
1210:
1202:
1201:
1198:on 2010-08-07.
1190:
1167:
1152:
1132:
1102:
1078:
1063:
1043:
1018:
1005:
976:
969:
936:
899:
856:
855:
853:
850:
849:
848:
843:
838:
833:
828:
823:
818:
813:
805:
802:
773:Main article:
770:
767:
746:
743:
724:
723:Implementation
721:
711:
708:
703:
699:
691:
687:
683:
679:
676:
675:
671:
668:
664:
661:
657:
654:
650:
639:
635:
631:
627:
624:
623:
619:
616:
612:
609:
605:
602:
598:
591:
590:
586:
583:
579:
567:
564:
555:
551:
547:
541:
537:
532:
526:
522:
517:
513:
507:
503:
498:
495:
481:
478:
421:
406:
405:
356:
354:
347:
341:
338:
319:Main article:
316:
313:
293:Main article:
290:
287:
285:relationship.
248:Main article:
245:
242:
222:Main article:
219:
216:
211:
208:
180:Andreas Reuter
135:
134:
49:
47:
40:
26:
9:
6:
4:
3:
2:
1729:
1718:
1715:
1713:
1710:
1708:
1705:
1704:
1702:
1687:
1679:
1677:
1669:
1667:
1659:
1658:
1655:
1649:
1646:
1644:
1641:
1639:
1636:
1634:
1631:
1629:
1626:
1624:
1621:
1619:
1616:
1614:
1611:
1609:
1606:
1604:
1601:
1599:
1596:
1595:
1593:
1589:
1583:
1580:
1578:
1575:
1573:
1570:
1568:
1565:
1564:
1562:
1558:
1552:
1549:
1547:
1544:
1542:
1539:
1537:
1534:
1532:
1529:
1527:
1524:
1522:
1519:
1517:
1514:
1512:
1509:
1508:
1506:
1502:
1496:
1493:
1491:
1488:
1486:
1483:
1481:
1478:
1476:
1473:
1471:
1468:
1466:
1463:
1461:
1458:
1454:
1451:
1449:
1446:
1444:
1441:
1440:
1439:
1436:
1435:
1433:
1429:
1423:
1420:
1418:
1417:Surrogate key
1415:
1413:
1410:
1408:
1405:
1403:
1402:Candidate key
1400:
1398:
1395:
1393:
1390:
1388:
1385:
1383:
1380:
1378:
1375:
1373:
1370:
1368:
1365:
1364:
1362:
1358:
1352:
1349:
1347:
1344:
1340:
1337:
1336:
1335:
1332:
1328:
1325:
1324:
1323:
1320:
1318:
1315:
1313:
1310:
1308:
1305:
1303:
1300:
1298:
1295:
1291:
1288:
1287:
1286:
1283:
1281:
1278:
1274:
1271:
1269:
1266:
1265:
1264:
1261:
1257:
1254:
1253:
1252:
1249:
1248:
1246:
1242:
1238:
1231:
1226:
1224:
1219:
1217:
1212:
1211:
1208:
1197:
1193:
1187:
1183:
1182:
1177:
1171:
1163:
1159:
1155:
1149:
1145:
1144:
1136:
1122:on 2016-03-03
1121:
1117:
1113:
1106:
1092:
1088:
1082:
1074:
1070:
1066:
1060:
1056:
1055:
1047:
1033:
1029:
1022:
1015:
1009:
1002:
990:
989:webopedia.com
986:
980:
972:
970:1-55860-190-2
966:
962:
957:
956:
950:
946:
940:
924:
920:
913:
909:
903:
895:
891:
887:
883:
879:
875:
871:
867:
861:
857:
847:
844:
842:
839:
837:
834:
832:
829:
827:
824:
822:
819:
817:
814:
811:
808:
807:
801:
798:
794:
790:
786:
782:
776:
766:
764:
760:
755:
753:
742:
739:
735:
734:shadow paging
731:
720:
718:
707:
697:
674:adds 10 to B.
669:
667:adds 20 to A.
662:
655:
648:
647:
646:
643:
622:adds 20 to A.
617:
610:
608:adds 10 to B.
603:
596:
595:
594:
584:
577:
576:
575:
572:
563:
561:
494:
492:
486:
419:
417:
413:
402:
399:
391:
381:
377:
373:
367:
366:
362:
357:This section
355:
351:
346:
345:
337:
335:
331:
327:
322:
312:
310:
306:
302:
296:
286:
284:
280:
276:
272:
268:
264:
260:
256:
251:
241:
238:
234:
230:
225:
215:
207:
205:
200:
198:
193:
189:
185:
181:
176:
174:
170:
166:
162:
158:
154:
150:
146:
142:
131:
128:
120:
109:
106:
102:
99:
95:
92:
88:
85:
81:
78: –
77:
73:
72:Find sources:
66:
62:
56:
55:
50:This article
48:
44:
39:
38:
33:
19:
1371:
1196:the original
1180:
1170:
1142:
1135:
1124:. Retrieved
1120:the original
1115:
1105:
1094:. Retrieved
1090:
1081:
1053:
1046:
1035:. Retrieved
1031:
1021:
1013:
1008:
999:
993:. Retrieved
988:
979:
954:
939:
927:. Retrieved
918:
902:
877:
873:
860:
778:
756:
748:
726:
713:
677:
644:
625:
592:
573:
569:
500:
487:
483:
409:
394:
385:
370:Please help
358:
324:
301:concurrently
298:
253:
229:Transactions
227:
213:
201:
187:
177:
172:
144:
138:
123:
114:
104:
97:
90:
83:
71:
59:Please help
54:verification
51:
1686:WikiProject
1577:Replication
1465:Transaction
1407:Foreign key
1387:CAP theorem
1334:Multi-model
1087:"Atomicity"
866:Haerder, T.
816:CAP theorem
717:disk buffer
560:foreign key
283:foreign key
279:primary key
263:constraints
255:Consistency
244:Consistency
184:Theo Härder
173:transaction
153:consistency
1701:Categories
1551:Query plan
1504:Components
1422:Unique key
1339:comparison
1273:comparison
1263:Relational
1256:comparison
1126:2016-02-28
1096:2016-12-13
1037:2023-07-14
995:2011-03-23
880:(4): 287.
870:Reuter, A.
852:References
326:Durability
315:Durability
259:invariants
233:statements
161:durability
87:newspapers
1560:Functions
1495:Partition
1322:In-memory
1280:Key–value
1162:436031093
1073:436031093
1001:complete.
945:Gray, Jim
929:March 27,
908:Gray, Jim
894:207235758
783:across a
480:Atomicity
359:does not
305:Isolation
289:Isolation
237:Atomicity
218:Atomicity
178:In 1983,
169:databases
157:isolation
149:atomicity
1666:Category
1582:Sharding
1438:Relation
1412:Superkey
1367:Database
1360:Concepts
1116:O'Reilly
951:(1993).
804:See also
686:fails, T
429:acidtest
388:May 2018
340:Examples
271:triggers
267:cascades
192:Jim Gray
117:May 2018
1676:Outline
1475:Trigger
1431:Objects
447:INTEGER
438:INTEGER
380:removed
365:sources
101:scholar
1490:Cursor
1448:column
1317:NewSQL
1188:
1160:
1150:
1071:
1061:
967:
892:
812:(BASE)
423:CREATE
103:
96:
89:
82:
76:"ACID"
74:
1480:Index
1443:table
1346:Cloud
1312:NoSQL
1307:Graph
1244:Types
915:(PDF)
890:S2CID
738:locks
529:= 100
510:= 100
453:CHECK
426:TABLE
330:crash
108:JSTOR
94:books
1531:ODBC
1521:JDBC
1460:View
1397:Null
1392:CRUD
1372:ACID
1327:list
1290:list
1268:list
1186:ISBN
1158:OCLC
1148:ISBN
1069:OCLC
1059:ISBN
965:ISBN
931:2015
846:CRUD
732:and
550:and
544:= 90
363:any
361:cite
188:ACID
182:and
145:ACID
80:news
1526:XQJ
1453:row
882:doi
474:));
471:100
416:SQL
374:by
139:In
63:by
1703::
1156:.
1114:.
1089:.
1067:.
1030:.
998:.
987:.
963:.
959:.
947:;
917:.
888:.
878:15
876:.
868:;
540:+
525:+
506:+
336:.
269:,
265:,
235:.
199:.
159:,
155:,
151:,
143:,
1229:e
1222:t
1215:v
1164:.
1129:.
1099:.
1075:.
1040:.
973:.
933:.
896:.
884::
704:2
700:1
692:1
688:2
684:1
680:1
672:1
670:T
665:2
663:T
658:2
656:T
651:1
649:T
640:2
636:1
632:1
628:2
620:2
618:T
613:2
611:T
606:1
604:T
599:1
597:T
587:2
585:T
580:1
578:T
556:A
552:B
548:A
542:B
538:A
533:A
527:B
523:A
518:B
514:A
508:B
504:A
468:=
465:B
462:+
459:A
456:(
450:,
444:B
441:,
435:A
432:(
401:)
395:(
390:)
386:(
382:.
368:.
281:–
147:(
130:)
124:(
119:)
115:(
105:·
98:·
91:·
84:·
57:.
34:.
20:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.