In the fields of [[database]]s and [[transaction processing]] (transaction management), a '''schedule''' (or '''history''') of a system is an abstract model to describe the order of [[Execution (computing)|executionexecutions]] in a set of transactions running in the system. Often it is a ''list'' of operations (actions) ordered by time, performed by a set of [[Database transaction|transactions]] that are executed together in the system. If the order in time between certain operations is not determined by the system, then a ''[[partial order]]'' is used. Examples of such operations are requesting a read operation, reading, writing, aborting, [[Commit (data management)|committing]], requesting a [[Lock (computer science)|lock]], locking, etc. NotOften, all transaction operation types should be included inonly a schedule,subset andof typicallythe only selectedtransaction operation types (e.g., data access operations) are included,asin neededa to reason about and describe certain phenomenaschedule.
Schedules and schedule properties are fundamental concepts in database [[concurrency control]] theory. A schedule describes the order of actions of the transactions as seen by the [[DBMS]]. In practice, most general purpose database systems employ conflict-serializable and recoverable (primarily strict) schedules.
