A database keeps information in a form that software can organise, find and update. As a business leader, you need to understand what the records mean, who owns them and what a report is actually counting.
You do not need to become a database administrator to ask useful questions. “Which record is the approved one?” is often a better beginning than choosing a technology.
Start with tables, rows and columns
In a relational database, information is organised into related tables. A row is a record; a column describes one field in that record. This is the model explained in the PostgreSQL introduction. Other kinds of database organise information differently.
Here is our invented orders table:
| Order ID | Customer ID | Status | Amount, GBP |
|---|---|---|---|
| O101 | C01 | Open | 120 |
| O102 | C02 | Paid | 80 |
| O103 | C01 | Open | 45 |
There are three orders and two different customer IDs. The repeated C01 means two orders for one customer, not necessarily a duplicate mistake.
An ID is a label used to distinguish a record. A primary key uniquely identifies rows in its table. A foreign key can require a customer ID in the orders table to match a record in a customer table. Those rules need to be defined and enforced. PostgreSQL's foreign-key tutorial explains the relationship.
A customer table might give C01 the fictional label “Practice Customer A”. Keeping the label there avoids retyping it differently on every order. It does not prove that the label is correct; somebody still owns data quality.
A database is not automatically the truth
Two systems may disagree because they serve different purposes. A sales pipeline may show a prospective order that the finance system has not invoiced. An exported spreadsheet may be a dated copy rather than the live record.
My proposed questions for the business owner are:
- Meaning: What counts as an order, a customer or an “open” item?
- Authority: Which system owns each field, and how are corrections approved?
- Timing: When was this view updated, and what period does it cover?
- Identity: Which IDs let us match records without guessing from similar names?
- Access: Who can read, export, change and delete each kind of information?
An AI that sees a column headed “customer” cannot work out all those rules reliably from the heading alone. Supply a small explanation of the fields, called a data dictionary. Begin with invented information while you learn.
Reading and changing are different jobs
A reporting account may only need permission to read selected information. An administrator can have much wider powers. OWASP's database guidance recommends giving database accounts only the privileges they need.
A transaction groups changes so they can succeed or fail together. Imagine recording both sides of an invented stock transfer. The PostgreSQL transaction tutorial explains the all-or-nothing principle. It does not make a mistaken instruction correct, and it is not a backup or universal undo button after a change is committed.
The business owner should approve the intended correction. A competent technical owner should handle the actual change and recovery arrangements. Do not give an AI production administrator access just to explain a table.
Ask your AI to teach you
Keep the learning chat disconnected from live systems. The prompt is a teaching instruction, not technical enforcement of read-only access.
Check that you can use it
The sample contains three orders, two customers and GBP165 of open orders. Explain why each answer uses a different rule. If someone asks for “total sales”, ask whether they mean open orders, paid orders, invoices or another measure before calculating.
Your useful output is a short data dictionary and a list of questions for the system owner. Continue with SQL, or see keeping business data secure.
Sources and boundaries
The PostgreSQL and OWASP sources were checked on 21 October 2026. Their concepts support the explanations, not a recommendation to migrate to a particular database. The figures are invented and the management questions are proposed practice. The lesson makes no claim to audit a live schema, access policy or business report.