A3.1 Database fundamentals

Databases and database management systems

From files to databases

A program can store data in an ordinary file, such as a text file with one line per record and commas between the values. For a small list that works. Problems start when the same file must hold several kinds of fact at once, and when several people or programs need it at the same time.

The simplest way to organise a database is a single table holding everything, much like one sheet of a spreadsheet.

A school library that records loans in a flat file needs one row per loan, and each row must repeat everything about the member and the book, because there is nowhere else to put it. The flat file of loans shows the result. (Good Omens was written by Terry Pratchett and Neil Gaiman together; Mort is by Pratchett and Coraline by Gaiman.)

Aisha's name and year group are stored three times, and the details of Good Omens three times. If Aisha moves into Year 13, three rows must change; if one is missed, the file gives two different answers to the question "which year is Aisha in?". A member who has never borrowed a book cannot be recorded at all, because every row is a loan, and deleting the only loan of Mort also deletes the only record that the library owns Mort. These faults are called update, insertion and deletion anomalies, and subtopic A3.2, Database design, shows how normalisation removes them.

The relational alternative

A relational database solves the problem by splitting the data into several tables, one for each kind of thing: members in one table, books in another, loans in a third. Each table holds only the facts about its own kind of thing, and the tables are joined by shared values.

In the relational version of the library, the Loan table stores only a member's ID and a book's ID with the date. To find the name of the member who borrowed a book, the software looks up that ID in the Member table. Aisha's year group is stored once, in one row of the Member table, so a change happens in one place and every loan sees it.

The database management system

The data in a database lives in files on secondary storage, but users and programs almost never touch those files directly. They send requests to a program that manages the files for them.

The diagram of a DBMS shows why it matters. Every application (the library app, the school website, a reporting tool) talks to the DBMS, and only the DBMS reads and writes the database files, so every request passes the same checks.

This single point of control explains most of the benefits of a relational database. Rules are written into the database once, not into each program; two programs cannot corrupt each other's changes; and the DBMS can restore the data after a crash. A flat file read by several programs has none of this: each program must enforce its own rules, and a bug in any one of them can damage the data for all.

Features of a relational database

The five features of a relational database are tables, primary keys, foreign keys, composite keys and relationships. Each answers one question: where the data is kept, how each record is identified, how records in different tables are linked, how a record is identified when no single field is enough, and how many records on each side of a link can be connected.

Tables, records and fields

Each table in a relational database stores data about one kind of real-world thing, called an entity.

The anatomy of the Member table shows the vocabulary. Each row is a record about one member; each column is a field holding one property; and the value where a row meets a column is a single field value, such as Aisha's year group.

Every value in a field has the same data type and meaning: YearGroup always holds a whole number for a year group, never a name or a date. The DBMS stores the type of each field as part of the table's schema, the description of the tables, fields and links that the data must fit.

Primary keys

The library may have two members called Mei Chen, and two copies of the same book. If records could be picked out only by name, no query could single out one of the two members. Every table therefore has a primary key.

A good primary key has three properties. It is unique (no two records ever share a value), it is never null (every record has one) and it is stable (it does not change during the record's life). Names fail the first test, and phone numbers or email addresses fail the third, since people change them. For this reason, most tables use an ID created for the purpose, such as MemberID or BookID, which carries no meaning beyond identifying the record.

Foreign keys and relationships

A primary key identifies a record inside its own table. To link records in two tables, the primary key of one table is stored as an ordinary field in the other.

In the library, the Loan table stores MemberID and BookID. Each is a foreign key: Loan.MemberID refers to Member.MemberID, and Loan.BookID refers to Book.BookID. The diagram of the two linked tables shows the reference as an arrow from the foreign key to the primary key it must match.

A loan for member M001 holds only the value M001; Aisha's name is found by matching that value with the Member table. Retrieving data from two tables by matching a foreign key with a primary key is called a join, and writing joins in Structured Query Language (SQL) is part of subtopic A3.3, Database programming.

A foreign key may also refer to the primary key of its own table. A Staff table with a ManagerID field that holds another member of staff's StaffID links each employee to their manager inside one table. Self-referencing tables of this kind are the usual relational way to store trees such as staff and their managers, although querying a whole tree through them is awkward, one of the limitations of the relational model.

Types of relationship

The link created by a foreign key is a relationship, and every relationship has a type that says how many records on each side can be connected.

One-to-many is by far the most common type. A useful check for which side is "many": read the relationship both ways. "One member has many loans" and "one loan has one member" confirm that Loan is the "many" side, so the foreign key MemberID belongs in Loan. Putting it the other way round, a LoanID field in Member, would let a member have only one loan.

Composite keys and link tables

Some tables have no single field that is unique. In the library, Good Omens has two authors and Terry Pratchett wrote many books, so Book and Author have a many-to-many relationship. A relational table cannot store a list of authors in one field of a book, or a list of books in one field of an author, so a third table, a link table, records each book–author pair as its own row.

In the BookAuthor link table, BookID repeats (B101 has two authors) and AuthorID repeats (A01 wrote two books), so neither field alone can be the primary key. The pair of values together is unique, because the same author is listed against the same book only once.

The diagram of the link table shows the result: the many-to-many relationship between Book and Author becomes two one-to-many relationships, each built from an ordinary foreign key.

Composite keys also appear outside link tables. A school timetable might identify a lesson by (RoomID, Day, Period), since a room holds only one lesson at a time. Some designers prefer to add a single generated ID to every table instead; subtopic A3.2, Database design, compares these choices.

Benefits: storing each fact once

Reduced data duplication and redundancy

The flat file of loans stored the same values again and again. Two closely related terms describe this.

Duplication describes copies of a value, whereas redundancy describes whether a value is needed at all. A value is redundant when removing it would lose no information, because it is already stored elsewhere or can be worked out from other data.

The two terms are often used as if they meant the same thing, and in most cases they describe the same problem. The difference matters at the edges. The foreign key M001 stored in each of Aisha's loan rows is duplication but not redundancy, because each copy records a different loan. Aisha's year group stored in three loan rows is both: the copies add nothing, since one copy says it all.

A relational database reduces both because each fact has exactly one home. Aisha's name and year group live in one Member record; the title and genre of each book in one Book record. The only values repeated across tables are short key values, and those repeats are what link the tables.

Data consistency

Storing each fact once also saves the database from holding two copies of a fact that disagree.

In the flat file, an update that changes two of Aisha's three rows leaves the file inconsistent: one query reports Year 13 and another Year 12, and nothing shows which is right. In the relational design Aisha's year group exists in one record, so every loan, report and screen that needs it reads that single value, and one update changes it for all of them at once.

Benefits: data integrity

Entity, referential and domain integrity

The DBMS can refuse data that breaks rules written into the schema. This protects the quality of the data far better than checks scattered through each application.

Relational databases enforce three standard kinds of integrity, each tied to one of the features already described.

Entity integrity is what the primary key guarantees. Without it two members could both be M002, and a loan recorded against M002 would be ambiguous.

Referential integrity is what the foreign key guarantees. The DBMS refuses a loan for member M009 if no such member exists, and it refuses to delete member M001 while loans still refer to that member, unless the designer has told it to delete or update the linked records too (a "cascade").

Domain integrity comes from the data types chosen for each field and from extra checks. A YearGroup field defined as a whole number from 7 to 13 cannot hold 15 or "twelve". Subtopic A3.2, Database design, explains how to choose data types such as CHAR and VARCHAR.

Integrity constraints in action

The rules are written into the schema as constraints.

The SQL statements that create the library's tables show each kind of constraint. SQL is taught in subtopic A3.3, Database programming; here only the constraint keywords matter.

With members M001 to M003, books B101 to B103 and three loans already stored, the following five changes were sent to the DBMS (SQLite 3.43, with foreign key checks switched on).

Every one was rejected. The messages are those printed by SQLite.

Constraints check only that data is valid (of the right form and linked correctly), not that it is true. A loan dated 2026-09-01 that really happened on 2026-09-10 passes every constraint, as does a member whose surname is misspelt. Accuracy still depends on careful data entry and on validation in the programs that collect the data.

Benefits: many users at once

Transactions

Many changes to a database come in groups that only make sense together. Moving 100 euros from one bank account to another is two changes: subtract 100 from the first balance, add 100 to the second. If the system fails between the two, the money has left one account and arrived nowhere.

The DBMS keeps a record of the changes a transaction makes until the transaction finishes. If every step succeeds the transaction is committed and its changes become permanent; if any step fails, or the system crashes part-way, the DBMS rolls back the partial changes, as if the transaction had never started. The library's "borrow a book" action is a transaction too: insert a Loan record and mark the book as on loan, both or neither.

Concurrency control and locking

A school library with one librarian rarely has two changes at the same moment. A concert ticket website, a bank or an airline booking system has thousands. When two transactions read and change the same data at the same time, their steps interleave, and without control they can produce results that neither user intended.

The classic case is the lost update. A concert has one seat left. Two customers press "Book" at almost the same moment, and each booking transaction reads the number of seats left, checks that it is above zero, then writes the new value.

Both customers receive a ticket for the same seat. T2's decision was based on a value that T1 had already made out of date, and T1's update is lost underneath T2's, even though each transaction would have worked correctly if it had run alone.

The most common method is locking.

With locking, T1 locks the concert's record before reading it. T2 must wait for the lock, and when it finally reads the record, it sees the up-to-date value.

The result is the same as if T1 had run completely before T2: one ticket sold, one customer told the event is full. Locks have costs. A transaction that waits is slower, so locks are held for as short a time as possible and usually on single records rather than whole tables. Two transactions can also each hold a lock the other needs and wait forever, a deadlock; a DBMS detects this and rolls one of them back so that the other can finish.

Reliable transaction processing

Transactions and concurrency control together give reliable transaction processing: every transaction either happens completely or not at all, concurrent transactions do not corrupt each other, and committed changes survive power cuts and crashes because the DBMS writes them to non-volatile storage, with a log it can replay, before it confirms them. These guarantees are a main reason why banks, airlines, hospitals and shops keep their core records in relational databases. A customer who is told "payment complete" can trust that the payment is recorded exactly once, even if the server fails one second later.

Benefits: retrieval, scale, security and support

Data retrieval

Data is stored in order to be found again. A relational database answers questions in SQL, a declarative language: the user states what result is wanted ("the titles of all books borrowed by members in Year 12 in September") and the DBMS works out how to find it, choosing which tables to read first and whether to use an index. The same small set of operations (select rows, choose columns, join tables, group and sort) answers almost any question, including questions nobody thought of when the database was designed.

Because the data is held in separate, linked tables, a query can combine them in any direction: all loans of one member, all members who borrowed one book, every book never borrowed. A flat file supports only the questions its layout was built for, and anything else needs a new program to read and filter it. Indexes, sorted lookup structures that the DBMS keeps for chosen fields, let it find matching records without reading every row, so retrieval stays fast as tables grow to millions of records.

Scalability

Scalability is the ability of a system to handle a growing amount of data and users by adding resources. Relational databases scale well in two common ways:

• Vertical scaling: moving the database to a more powerful server with more processor cores, more memory and faster storage. One modern server can hold billions of rows and serve thousands of transactions per second.

• Read replicas: keeping copies of the database on extra servers that answer read-only queries, while one main server handles every change. A news site with millions of readers and a few editors fits this well.

Both approaches have limits, and these limits underlie the "big data" scalability problem. Vertical scaling stops at the largest machine that can be bought, and read replicas do not help a system whose problem is too many writes.

Security features

Because every request passes through the DBMS, the DBMS can control who does what. Relational DBMSs typically provide:

• User accounts and authentication: each person or program logs in, so the DBMS knows who is making each request.

• Privileges (access control): each account is granted only the operations it needs on each table. A library assistant may read and add loans but not delete members; a reporting program may only read.

• Views: a stored query that shows a user only some rows or columns of a table, such as members' names without their home addresses.

• Encryption of the stored files and of connections, so stolen disks or intercepted traffic do not reveal the data.

• Audit logs recording who changed what and when, which help detect misuse and are often required for personal data.

These features matter because databases hold the most sensitive data an organisation has: names, addresses, health records, payments. Data protection laws such as the General Data Protection Regulation (GDPR) require organisations to protect personal data and to limit who can see it, and a DBMS's privileges and logs are the usual way to show that they do.

Community support

Relational databases have been in wide use since the late 1970s, so a very large body of knowledge surrounds them. Community support includes official documentation, books and courses, public forums where problems have already been asked and answered, free open-source systems (PostgreSQL, MySQL, SQLite) and tools for design, backup and monitoring. SQL itself is an international standard, first adopted by ANSI in 1986, so the skills transfer between systems with only small differences in syntax.

For an organisation, this lowers risk and cost. Developers who know SQL are easy to hire; bugs and security flaws in popular systems are found and fixed quickly because many people use them; and a system chosen today will still be supported in ten years. A newer kind of database may suit a problem better on paper but come with fewer experts, less documentation and less certainty about its future.

Limitations of a relational database

"Big data" scalability issues

Some organisations collect data on a scale that no single server can hold or process.

Handling big data means spreading it across many servers, each holding part of the data. Relational databases find this hard for two reasons. A join must match records that may sit on different machines, so the data travels across the network before the query can finish. And a transaction that changes records on several servers must lock and commit on all of them together, which means rounds of messages between servers for every change. As the number of servers grows, this coordination slows writes and makes failures harder to handle.

Cassandra, now Apache Cassandra, is one example. Engineers at Facebook built it to store the data for Facebook's inbox search, where the volume of messages and the rate of new ones suited a store spread across many machines better than a relational database, and Facebook released it as open-source software in July 2008. Systems of this kind, called NoSQL databases, usually give up joins and some transaction guarantees in exchange for spreading data easily; they are HL content in subtopic A3.4.

Design complexity

A relational database works well only if its tables are designed well, and good design takes skill. The designer must identify the entities, decide which fields belong in which table, choose primary keys, add link tables for many-to-many relationships and apply normalisation so that no fact is stored twice. A library needs three or four tables; a hospital or an online shop may need hundreds, with relationships that are hard to see as a whole.

Poor design decisions are costly to reverse. A field put in the wrong table, or a relationship modelled as one-to-many when it is really many-to-many, may only be discovered when the database holds years of data and dozens of programs depend on its layout. Normalised designs also spread data across many tables, so even simple questions need several joins, which makes queries harder to write and, on large tables, slower to run. Subtopic A3.2, Database design, covers the methods (entity–relationship diagrams, normalisation) and when designers deliberately undo normalisation for speed.

Rigid schema

Before any data can be stored, a relational database needs its schema: every table, field, data type and constraint defined in advance.

The rigid schema is the source of many benefits: because every record has the same fields and types, the DBMS can check domain integrity, store records compactly and plan queries efficiently. It becomes a limitation when the data changes shape. If the library starts lending laptops, which have a serial number and a charger but no author or genre, it must either add fields that are empty for every book or design new tables. On a table of millions of records, adding or changing a column can take a long time and may lock the table while it happens, and every program that reads the table may need updating. Data whose structure varies from record to record, or changes every few weeks, fits a rigid schema badly.

Hierarchical data handling

Much real data forms trees: a company's staff and managers, a folder structure, the categories of a library catalogue, a discussion thread where replies have replies.

A relational table stores a tree with a self-referencing foreign key: each record holds the ID of its parent. The library's category table holds Fiction, then Fantasy (parent Fiction), then Comic fantasy (parent Fantasy). Storing the tree is straightforward, but following it is harder, because a single join moves only one level, and the number of levels varies from one branch to another. The function path_to_top walks up the tree from any category to the top, one lookup per level, and counts the lookups.

Both versions print the same output. The Python version marks a category with no parent by None; the Java version stores every value in a String[][] array, so IDs are strings and a missing parent is null.

Each lookup in the loop stands for one query to the database, so a tree ten levels deep needs ten queries, and the program cannot know the depth in advance. Questions such as "every reply anywhere under this comment" are harder still. Standard SQL added recursive queries in 1999 to handle this, but they are harder to write than ordinary queries and can be slow on large, deep trees. Graph databases, an HL topic in subtopic A3.4, store links between items directly and follow them without joins.

Unstructured data handling

A relational table expects every value to be small, typed and meaningful on its own: a name, a number, a date. Much of the data that organisations now collect does not look like that.

A relational database can store an image or a document as one large binary value, but it cannot look inside it. A query cannot ask for "photos containing a dog" or "emails that sound angry", because to the DBMS the value is only a sequence of bytes with no fields inside it. Data that is partly structured, such as JSON documents whose fields vary from one record to the next, is semi-structured data; it fits a relational table only after being forced into fixed columns or stored whole as text. Systems that hold large amounts of unstructured data (search engines, social media, sensor archives) usually keep it in file stores or non-relational databases, often with a relational database alongside for the structured parts, such as user accounts and payments.

Object-relational impedance mismatch

Most programs that use a database are written in object-oriented languages such as Python and Java, where data is held in objects created from classes. An object can contain a list, refer to other objects and inherit from a parent class. A table can contain none of these: every field holds one simple value.

A Book object naturally holds its list of authors. To store it, the program must split the object across two tables (a row in Book and one row per author in BookAuthor), and to load it again it must collect the rows and rebuild the list. The program does both. For brevity, the link rows hold author names rather than AuthorID values.

The two programs print identical output. Java holds the authors in an ArrayList<String> because its length can grow, and each table row in a fixed-length String[] array, where Python uses lists for both.

One object became three rows in two tables, and rebuilding it needed a search through the link rows. A real application repeats this for every class, and the mismatch goes further than lists: tables have no inheritance (a Laptop subclass of LibraryItem has no direct table equivalent), objects refer to each other by memory reference while rows refer by key value, and object identity (the same object in memory) differs from row identity (the same primary key).

An ORM removes most of the repetitive conversion code, but it does not remove the mismatch itself. It can generate inefficient queries, for example one query per object where a single join would do, and developers still need to understand the tables underneath to find out why a program is slow.

Weighing benefits against limitations

The benefits and limitations are two sides of the same design choices. Fixed tables with typed fields give integrity and efficient queries, and the same fixity makes change slow and unstructured data awkward. Splitting data into linked tables removes duplication and gives consistency, and the same splitting makes design complex and big-data scaling hard.

A relational database is the strong choice when the data has a stable, regular structure, when correctness matters more than raw speed, and when many users change shared records: banking, bookings, school records, stock control, payroll. It is a weaker choice for data that is huge and spread across many servers, changes shape often, is mostly free text or media, or is mainly a network of links. Many real systems combine both, using a relational database for accounts and payments and another store for the rest.

Case study: SQLite

SQLite is a relational database engine designed by D. Richard Hipp in 2000; version 1.0 was released in August 2000. Unlike most relational DBMSs, it does not run as a separate server. It is a small library compiled into the application that uses it, and it keeps a complete database (tables, indexes, constraints) in one ordinary file. Its developers describe it as "the most widely deployed database engine", because it is built into every Android and iOS device, every Windows 10 and 11 installation, and the Firefox, Chrome and Safari browsers.

Source: sqlite.org ("About SQLite", "Most Widely Deployed and Used Database Engine", "Appropriate Uses For SQLite", "How SQLite Is Tested"), October 2026.

What SQLite shows about the benefits

SQLite is a clear example of community support. Being public domain, it costs nothing to include in any product, its documentation is extensive, and its very wide use means problems are found and fixed quickly; its developers write about 590 lines of test code for every line of the library. A student can install it in minutes, and Python includes it in its standard library as the sqlite3 module, which makes it a convenient engine for practising SQL.

SQLite also shows data integrity, transactions and concurrency control in a small package. It supports primary keys, foreign keys, NOT NULL, UNIQUE and CHECK constraints, and its changes are made in transactions that either complete or roll back, even if the device loses power part-way through a write. It controls concurrency by locking the database file, so a phone's messaging app and its backup service can use the same database without corrupting it.

What SQLite shows about the limitations and trade-offs

The single-writer design is a deliberate trade-off. Its developers state that SQLite allows only one writer at any instant, with other writers queuing; for a phone app or a browser this is never a problem, but a website where thousands of users change data every second needs a client–server DBMS such as PostgreSQL. SQLite's own documentation recommends a client–server database when the data is separated from the application by a network, a clear example of choosing the database for the scale of the problem.

SQLite also shows how a default setting can weaken integrity. For compatibility with older programs, it does not check foreign key constraints unless each connection switches them on, and it allows null values in most primary key columns unless the column is declared NOT NULL (which is why the library's tables declare it). The library database in the constraint test rejected the loan for member M009 only because foreign key checks had been switched on. The same loan, sent twice to the library database with the setting off and then on, shows the difference.

The first INSERT succeeds and stores loan 4 for a member who does not exist; the second fails with FOREIGN KEY constraint failed. A developer using SQLite must therefore switch the checks on in every connection for referential integrity to be enforced.

Exam focus

Database fundamentals are examined in Section A of Paper 1, usually as the first parts of a longer question set around a scenario such as a library, school, clinic or online shop. Questions on database fundamentals lean on the command term explain, so the later parts of a question expect a reason or mechanism, not just a name. Expect a mix of:

• identify or state parts (1–2 marks): the primary key of a table, a foreign key, the type of a relationship, a composite key in a link table;

• outline or describe parts (2–3 marks): what a foreign key does, how a link table resolves a many-to-many relationship;

• explain parts (2–6 marks): a benefit such as concurrency control or referential integrity, or two limitations for a given kind of data, each with its reason in the scenario.

SQL and table design are examined through the same scenarios, in subtopics A3.2 and A3.3, so the keys and relationships identified in early parts are often reused later.

The commonest way to lose marks on database fundamentals is to name a benefit or limitation without its mechanism or context. Marks for explain come in pairs: what the feature does, and why that matters for the data in the question.

Practice questions

1. Define the term foreign key. [1]

2. State two properties that every primary key value must have. [2]

3. Outline the difference between data duplication and data redundancy. [2]

4. A hospital stores Doctor(DoctorID, Name), Patient(PatientID, Name) and Appointment(DoctorID, PatientID, AppointmentDateTime, Room). A doctor sees only one patient at a time. Identify the primary key of Appointment, and state the relationship between Doctor and Patient that Appointment resolves. [2]

5. Distinguish between data consistency and data integrity. [2]

6. Explain how a relational database maintains entity integrity and domain integrity. [4]

7. A bank transfers money between two accounts. Explain why the transfer is processed as a transaction. [3]

8. Explain why a relational database is difficult to scale to the volume of data produced by a global social network. [3]

9. Explain the object-relational impedance mismatch, with reference to an object that holds a list. [3]

10. A small charity wants a system to record donors, donations and the campaigns they support. Evaluate the use of a relational database for this system. [6]

Summary

• A database is an organised, persistent collection of related data; a DBMS is the software that controls all access to it and enforces its rules for every application.

• A flat file repeats data in every row, which causes inconsistency and update, insertion and deletion anomalies; a relational database splits data into linked tables.

• Features: tables (one per entity) of records (rows) and fields (columns); a primary key identifies each record; a foreign key matches the primary key of another table; a composite key uses two or more fields; relationships are 1:1, 1:M or M:N, with M:N resolved through a link table.

• Storing each fact once reduces duplication and redundancy and keeps the data consistent.

• Integrity constraints enforce entity integrity (unique, non-null keys), referential integrity (foreign keys match real records) and domain integrity (values of the right type and range); they check validity, not truth.

• Transactions are all-or-nothing units of work; concurrency control, usually by locking, stops interleaved transactions from causing lost updates, giving reliable transaction processing.

• Further benefits: flexible declarative retrieval with indexes, vertical scaling and read replicas, security features (accounts, privileges, views, encryption, audit logs) and strong community support.

• Limitations: big data is hard to spread across many servers; design is complex; the schema is rigid; trees need one join per level; unstructured data cannot be queried by content; objects do not map neatly to tables (impedance mismatch, eased by ORMs).

• Benefits and limitations come from the same design choices, so the right database depends on the structure, size and use of the data.

Self-check

• To do:

  I can explain why a flat file leads to duplicated and inconsistent data, using a table of my own.

• To do:

  I can label a table's records, fields, field values and primary key.

• To do:

  I can choose a primary key for a table and justify why other fields are unsuitable.

• To do:

  I can identify the foreign keys in a set of tables and say which primary key each refers to.

• To do:

  I can state the type of each relationship and place the foreign key on the "many" side.

• To do:

  I can resolve a many-to-many relationship with a link table and identify its composite key.

• To do:

  I can distinguish data duplication from data redundancy, and data consistency from data integrity.

• To do:

  I can identify which kind of integrity (entity, referential, domain) a constraint protects.

• To do:

  I can explain why integrity constraints cannot guarantee that data is true.

• To do:

  I can trace a lost update between two transactions and show how locking prevents it.

• To do:

  I can explain each benefit with its mechanism and a consequence in a scenario.

• To do:

  I can explain each limitation with its cause, including big-data scaling, rigid schema and impedance mismatch.

• To do:

  I can evaluate whether a relational database suits a given system and reach a justified judgement.

[1]1 mark