AI Glossary / Data engineering and architecture / Advanced
Database semantics
Definition
In AI logic, database semantics interprets a knowledge representation using assumptions that make its recorded facts describe a definite, bounded world. The usual assumptions are unique names, a closed world and domain closure.
What it means
Ordinary first-order logic permits more possibilities than a simple list of records may suggest. Different names might refer to the same object, additional unnamed objects might exist, and an unrecorded fact need not be false.
Database semantics adds restrictions. Unique names treats different constant names as different objects. Domain closure limits the domain to the named objects. The closed-world assumption treats facts not established as true as false within the chosen representation.
These are modeling choices, not discoveries about reality. They are useful when the system has a complete, controlled description of a small domain. They become misleading when missing information is merely unknown. This specialized AI meaning is distinct from the broader phrase “database semantics,” which can refer generally to the meaning of schemas, queries or stored data.
How it works
First specify the objects, predicates and scope of the represented world. Determine which names identify distinct objects and whether the object list is complete. Then decide which relations can be treated as complete enough for absence to count as falsity.
For a simple function-free collection of ground facts, the listed object names and predicate tuples define a finite interpretation under these assumptions. If rules are also present, the treatment of derived facts and negation must follow the specified logical system; do not invent one universal rule for every logic-programming language.
This interpretation can simplify reasoning because fewer possible worlds remain. The trade-off is commitment: the system now draws negative conclusions and object-distinctness conclusions that ordinary first-order statements alone may not justify.
Three practical examples
1. Classical planning: a fully specified toy world lists named packages, vehicles and their current locations, allowing a planner to reason from a state.
2. Controlled configuration: a system enumerates the components available for one particular assembly and treats unlisted component relationships as absent within that bounded configuration.
3. AI knowledge review: a team checks whether an assistant is incorrectly turning “not found in this collection” into “does not exist,” especially when the collection is incomplete or access-filtered.
Think of it this way
Think of the official seating chart for one small event, declared complete. If a named guest has no assigned seat in that complete chart, the system can conclude that the chart assigns none. The analogy fails if the chart is an unfinished draft or omits another room. Likewise, database semantics is only appropriate when its completeness and identity assumptions match the intended scope.
Worked example
Consider a tiny domain containing exactly three objects named CardA, CardB and CardC. The only predicate is Marked(x), and the recorded facts are Marked(CardA) and Marked(CardC).
Under unique names, CardA, CardB and CardC denote three distinct objects. Under domain closure, there are no additional objects in this toy domain. Under the closed-world assumption, Marked(CardB) is false because it is absent from the complete list. The interpretation has exactly two marked objects.
Under ordinary first-order semantics without those extra assumptions, the same positive facts do not by themselves establish that CardB is unmarked, that the names are all distinct, or that no other marked objects exist.
Now suppose the records are only a partial inspection log. Applying the closed-world assumption would turn an uninspected card into an unmarked card. The formal inference would follow the chosen interpretation, but the interpretation would be unsuitable for the evidence.
Illustrative case study
Illustrative fictional case: Alder Catalogue builds an assistant that answers whether a product has a safety review. Its retrieved collection contains only reviews the current user may access. The assistant initially interprets absence as proof that no review exists.
A reviewer points out that the accessible collection is not the complete review register. The team changes the response to distinguish “no accessible review found” from a verified negative result from the authoritative complete source.
It also checks whether two product labels are aliases for one item before treating them as distinct objects. The fictional lesson is that closed-world and unique-name assumptions need explicit justification. The example is about information interpretation, not a legal or safety certification procedure.
Common misconceptions and mistakes
Do not treat missing evidence as false in an arbitrary web search, document collection or sensor feed. Do not assume two names always identify different real entities; aliases and duplicate records are common.
Do not confuse domain closure with access control: limiting what a user sees does not prove that no other objects exist. Do not assume SQL null handling is identical to this simplified two-valued logical interpretation. Finally, a finite set of names alone does not supply the intended meaning of each predicate or make every recorded fact correct.
Business use
Use database semantics deliberately in bounded reasoning tasks where the assumptions can be defended. Document which object inventory and relations are complete, their applicable time, and how changes are incorporated.
For AI products, examine negative answers especially carefully. “No matching record in this authorised snapshot” may be supportable where “this never happened” is not. Keep entity resolution separate from name matching, and avoid silently extending closed-world reasoning from a controlled operational table to an incomplete knowledge base. The benefit is precise reasoning within scope, not certainty about everything outside it.
People also ask
Is this how every database works?
No. This entry describes a particular logical interpretation used in AI texts. Real database systems have additional semantics, including nulls, permissions and transaction visibility.
Is an absent fact always false?
Only under the applicable closed-world assumption. Without that assumption, absence may leave the fact unknown.
Why require domain closure?
It rules out unnamed domain objects, making the represented object inventory complete. That is different from merely assigning distinct meanings to the names already present.
Check your understanding
A partial employee directory omits Dana. Can domain closure and a closed-world assumption be used to establish that Dana is not employed by the organization?
Answer: Not responsibly from that evidence. The directory is explicitly partial, so its absence does not justify the completeness assumptions needed for that conclusion.
Related terms
- Closed-world assumption
- Unique-names assumption
- Domain closure
- First-order logic
- Knowledge representation
- Classical planning
- open-world assumption
- ground atom
Learn next
Compare what a pair of positive facts entails under ordinary first-order logic and under the three additional assumptions. Then inspect one real dataset and identify which relations, if any, are complete enough to support negative conclusions within a stated time and access scope.
More in Data engineering and architecture
- Data Warehouse - A data warehouse is a data-management environment organized primarily for analysis and reporting, often integrating current and historical information from...
- Data warehouse automation - Data warehouse automation is the use of software to generate and manage repeatable parts of a data warehouse's lifecycle.
- Database - A database is an organized collection of data that can be stored, accessed and maintained as a coherent whole.
- Database-as-IPC - Database-as-IPC means using a database as a channel for inter-process communication: one process writes information that another reads to discover work or...
- Database Client - A database client is a program or software component that requests database services, such as running queries and receiving results.
- Database connection - A database connection is the communication context through which a program interacts with a database.
Sources
AIMA-based first-order logic teaching material, explicit database-semantics assumptions: https://people.sabanciuniv.edu/~berrin/cs404/lectures2018/chapter08-aima-by.pdf
Russell and Norvig, first-order logic semantics, official teaching slides: https://aima.cs.berkeley.edu/slides-pdf/chapter08.pdf
Stony Brook University, classical planning and database-semantics state assumptions: https://www3.cs.stonybrook.edu/~sael/teaching/cse537/Slides/chapter10b.pdf
The card and review-collection examples are original illustrations of the assumptions' consequences and limits.
Previous: Database schema Next: Database transaction