INFO20003 Chap.1 Database Systems and Design Lifecycle
Database Systems and Design Lifecycle
A database system combines persistent data, management software, applications, people and rules. This chapter separates raw data from decision-ready information, explains the responsibilities of a DBMS, and follows a development project from organisational requirements through conceptual, logical and physical design into implementation and maintenance.
The central skill is classifying a decision at the right level so business meaning is settled before storage details are chosen. The database approach replaces isolated files with a managed representation that can support shared definitions, controlled access, integrity checking, concurrency and recovery.
Those benefits create responsibilities: the organisation must define ownership, authorisation, backup policy and acceptable performance instead of assuming that the DBMS supplies correct policy automatically. Data independence is the useful boundary. Applications should rely on a stable logical view while administrators can alter physical access structures without changing what each stored fact means.
A lifecycle answer is strongest when it identifies both the deliverable and its reviewer. Requirements are checked with stakeholders for completeness and conflict. A conceptual model is validated as a faithful account of entities, relationships and constraints. A logical schema is checked for keys, domains and integrity. Physical choices are evaluated against workload and resource evidence.
Implementation, data conversion and application testing then demonstrate that those layers work together. Operation supplies evidence for another iteration: new regulations can change rules, new workloads can change indexes, and observed data-quality failures can reveal a missing constraint. Traceability prevents a local fix from becoming a new inconsistency.
For any proposed change, follow the reason forward from requirement to model, schema and implementation, then follow it backward from the database object to the business purpose it serves. Distinguish verification from validation as part of that chain. Verification asks whether an artefact conforms to its approved predecessor; validation asks whether it solves the users' actual problem.
A schema can verify perfectly against an incomplete model and still be the wrong database. The design levels therefore organise evidence and responsibility, not merely project vocabulary.
What this chapter covers
- 01
Data and information
- 02
DBMS components
- 03
Requirements analysis
- 04
Conceptual design
- 05
Logical design
- 06
Physical design
- 07
Implementation and testing
- 08
Operational feedback
Worked example · free
Place decisions in the design lifecycle
- 1Interviews gather requirements and constraints before a representation is selected.
- 1Entities and relationships express conceptual meaning.
- 1Keys and relations belong to logical design.
- 1The index is a physical access choice that leaves business meaning unchanged.
Key terms
- Data
- Recorded facts that have not necessarily been interpreted for a decision.
- Information
- Data processed and placed in context so it becomes useful to a user.
- Conceptual design
- A technology-independent representation of domain entities, relationships and constraints.
- Logical design
- The translation of conceptual meaning into relations, keys and integrity rules.
- Physical design
- The choice of files, indexes and storage arrangements used to implement a logical schema.
- Metadata
- Information describing the structure, meaning or permitted representation of stored data.
Database Systems and Design Lifecycle FAQ
How do I verify traceability across the lifecycle?
Select one business rule and follow it through the conceptual model, logical constraint and implementation test. Then reverse the path from the implemented object to the approved requirement. A missing link means either the rule is unenforced or the technical object lacks a demonstrated purpose; both findings require review at the earliest affected stage.
Why are there several database design levels?
They separate organisational meaning from implementation. Requirements and conceptual models can be validated with users before relations and keys are defined, while indexes and files can later change without rewriting the business facts the database represents.
Is the development lifecycle strictly one way?
No. Testing and operation expose missing requirements, weak constraints or unsuitable access paths. Those findings can send the team back to an earlier stage, where the model is corrected before the change is translated forward again.
How can I classify an unfamiliar design decision?
Look at its object. Business facts and constraints indicate requirements or conceptual work; relations and keys indicate logical work; pages, file organisations and indexes indicate physical work. Then explain what the decision changes.
Exam move
Choose a familiar application and write one example at each design level. Begin with a user need and a business rule, draw a conceptual relationship, map it into relations and identify one workload-driven index. Read the chain aloud to verify that no storage decision has been mistaken for a business rule.
When revising definitions, pair each term with a counterexample: a list of values is data, while an analysed workload report is information; a foreign key is logical, while a B+ tree is physical. Practise short classification questions until the reasoning sentence follows immediately after the label.
Working through Database Systems and Design Lifecycle in INFO20003? Sia is AskSia’s AI Computer Science tutor — ask any INFO20003 Database Systems and Design Lifecycle question and get a clear, step-by-step explanation grounded in how INFO20003 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.