Database Concepts
Chapter 8: Computer Science - Ultimate Study Guide | NCERT Class 12 Notes, Questions, Table Examples & Quiz 2025
Full Chapter Summary & Detailed Notes - Database Concepts Class 12 NCERT
Overview & Key Concepts
- Chapter Goal: Understand file system limitations, DBMS advantages, relational model (tables, keys), data organization. Exam Focus: Limitations (A-F), Tables 8.1-8.6, Fig 8.1-8.5, Keys; 2025 Updates: Emphasis on NoSQL vs RDBMS. Fun Fact: Quote on inconsistency ties to redundancy. Core Idea: Centralized data avoids chaos; from files to relations. Real-World: School DB. Expanded: All subtopics point-wise with evidence (e.g., Table 8.4 snapshots), examples (e.g., GUID foreign key), debates (e.g., file vs DBMS cost).
- Wider Scope: From manual records to relational schemas; sources: Tables (8.1-8.7), figures (8.1-8.5).
- Expanded Content: Include modern aspects like ER diagrams, normalization; point-wise for recall; add 2025 relevance like cloud DBs.
Introduction & Manual Limitations
- Manual Records: Attendance (50x26 entries/month); issues: Tedious, loss, errors.
- Office Files: Student/guardian details; search/modify hard.
- Computerized Need: Copy, find, add, modify, delete easily.
- Expanded: Evidence: Activity 8.1 shops; debates: Manual vs digital cost; real: Post-2020 online schools.
Conceptual Diagram: Manual to Digital Flow
Flow: Manual Register → Limitations (Redundancy) → Files (Partial) → DBMS (Relations + Keys). Ties to Fig 8.2.
Why This Guide Stands Out
Comprehensive: All subtopics point-wise, table integrations; 2025 with normalization, processes analyzed for schemas.
File System
- Files: Containers (text, CSV, images); access via programs.
- Example Tables: STUDENT (Table 8.1: Roll, Name, DOB, Guardian), ATTENDANCE (8.2: Date, Roll, Status).
- Limitations (A-F): Access (no mech), Redundancy (dup names), Inconsistency (mismatch), Isolation (no links), Dependence (struct change), Sharing (no control).
- Expanded: Evidence: Roll 3/5 same guardian; real: School promotion copy fails.
Quick Table: STUDENT (Partial - Table 8.1)
| Roll | SName | SDateofBirth | GName | GPhone | GAddress |
|---|---|---|---|---|---|
| 1 | Atharv Ahuja | 2003-05-15 | Amit Ahuja | 5711492685 | G-35, Ashok Vihar, Delhi |
| 2 | Daizy Bhutia | 2002-02-28 | Baichung Bhutia | 7110047139 | Flat no. 5, Darjeeling Appt., Shimla |
DBMS
- Definition: Software for create/manage DB; examples: MySQL, Oracle.
- Abstract View: Hides storage; interface for users/programs.
- Applications (Table 8.3): Banking (accounts), Inventory (orders).
- File to DBMS: Split STUDENT (add GUID), remove dup SName; links via Roll/GUID.
- Tables 8.4-8.6: STUDENT, GUARDIAN, ATTENDANCE snapshots.
- Environment (Fig 8.2): Users query → DBMS → Catalog/DB → Results.
- Expanded: Evidence: GUID unique; debates: DBMS cost (hardware/training).
Key Concepts in DBMS
- Schema: Design (tables, types, constraints, relations).
- Constraints: Restrictions (e.g., NOT NULL, UNIQUE on Roll).
- Meta-data: Data about data (catalog).
- Instance: Snapshot at time; changes via queries/manipulation.
- Query: Request info (SQL, next chapter).
- Manipulation: Insert/Delete/Update.
- Engine: Core for create/handle queries.
- Expanded: Evidence: NULL for unknown; real: Backup costs.
Relational Data Model
- Overview: Tables (relations) with rows (tuples), columns (attributes).
- Terms (Fig 8.4): Attribute (e.g., GName), Tuple (row), Domain (values set), Degree (cols=4), Cardinality (rows=5).
- Properties (3): Unique attr names/seq immaterial; Distinct tuples/seq immaterial; Same domain/atomic/NULL.
- Schemas (Table 8.7): STUDENT(Roll, SName, DOB, GUID), etc.
- Expanded: Evidence: Flat file; debates: Relational vs hierarchical.
Quick Table: GUARDIAN (Partial - Table 8.5)
| GUID | GName | GPhone | GAddress |
|---|---|---|---|
| 444444444444 | Amit Ahuja | 5711492685 | G-35, Ashok Vihar, Delhi |
| 111111111111 | Baichung Bhutia | 3612967082 | Flat no. 5, Darjeeling Appt., Shimla |
Keys in Relational DB
- Need: Unique tuples; at least one distinct attr.
- Candidate: Any unique attr (e.g., GUID, GPhone).
- Primary: Chosen candidate (e.g., GUID; others alternate).
- Composite: Multi-attr (e.g., {Roll, Date} in ATTENDANCE).
- Foreign: Links tables (e.g., Roll in ATTENDANCE → STUDENT; GUID in STUDENT → GUARDIAN; Fig 8.5).
- Expanded: Evidence: NULL allowed in FK; real: Referential integrity.
Summary & Exercise
- Key Takeaways: Files limited; DBMS centralizes; Relations link via keys; Constraints ensure integrity.
- Exercise Tease: Differentiate keys; design schemas; Q on tables.
Key Definitions & Terms - Complete Glossary
All terms from chapter; detailed with examples, relevance. Expanded: 30+ terms grouped by subtopic; added advanced like "Referential Integrity", "Normalization" for depth/easy flashcards.
File System
Container for data (CSV, text). Ex: STUDENT.txt. Relevance: Basic storage, but limited.
DBMS
Software for DB management. Ex: MySQL. Relevance: Centralized access.
Database
Related data collection. Ex: STUDENTATTENDANCE. Relevance: Logical organization.
Schema
DB design (tables, constraints). Ex: STUDENT(Roll PK). Relevance: Structure blueprint.
Constraint
Data restriction. Ex: UNIQUE Roll. Relevance: Integrity.
Meta-data
Data about data. Ex: Catalog. Relevance: Dictionary.
Instance
DB snapshot. Ex: Populated tables. Relevance: Current state.
Query
Info request. Ex: Find presents. Relevance: Retrieval (SQL).
Relation
Table in relational model. Ex: GUARDIAN. Relevance: Data storage.
Attribute
Column. Ex: GName. Relevance: Feature.
Tuple
Row. Ex: Amit Ahuja record. Relevance: Entity instance.
Domain
Attribute values set. Ex: Integers for Roll. Relevance: Type limit.
Degree
Number of attributes. Ex: 4 for GUARDIAN. Relevance: Width.
Cardinality
Number of tuples. Ex: 5 for GUARDIAN. Relevance: Size.
Primary Key
Unique identifier. Ex: GUID. Relevance: Distinction.
Foreign Key
Link to another table. Ex: Roll in ATTENDANCE. Relevance: Relation.
Candidate Key
Potential primary. Ex: GPhone. Relevance: Alternatives.
Composite Key
Multi-attribute PK. Ex: {Roll, Date}. Relevance: Combined unique.
Data Redundancy
Dup data. Ex: Names in two files. Relevance: Waste/inconsistency.
Data Inconsistency
Mismatch dup. Ex: Name spelling diff. Relevance: Errors.
NULL
Unknown/non-applicable. Ex: No phone. Relevance: Flexibility.
Referential Integrity (Advanced)
FK matches PK. Ex: Valid GUID. Relevance: Valid links.
Normalization (Advanced)
Reduce redundancy. Ex: Split tables. Relevance: Efficiency.
Tip: Group by model/keys; examples for recall. Depth: Debates (e.g., NULL risks). Historical: Codd's relational. Interlinks: To SQL Ch9. Advanced: Joins. Real-Life: E-commerce DB. Graphs: Schema Fig 8.5. Coherent: Evidence → Interpretation. For easy learning: Flashcard per term with table snippet.
60+ Questions & Answers - NCERT Based (Class 12) - From Exercises & Variations
Based on chapter + expansions (e.g., Ex Q1-13). Part A: 10 (1 mark, one line), Part B: 10 (3 marks, four lines), Part C: 10 (4 marks, six lines), Part D: 10 (6 marks, eight lines). Answers point-wise in black text. Include tables where apt.
Part A: 1 Mark Questions (10 Qs - Short)
1. What is a file system?
Data container on storage.
2. Define DBMS.
DB management software.
3. Name one limitation of file system.
Data redundancy.
4. What is a relation?
Table in relational model.
5. Define primary key.
Unique tuple identifier.
6. What is degree of a relation?
Number of attributes.
7. Example of foreign key?
GUID in STUDENT.
8. What is NULL?
Unknown value.
9. Define cardinality.
Number of tuples.
10. What is schema?
DB design.
Part B: 3 Marks Questions (10 Qs - Medium, Exactly 4 Lines Each)
1. Differentiate file system vs DBMS.
- File: Isolated, redundant.
- DBMS: Centralized, linked.
- Ex: Dup names vs keys.
- DBMS overcomes limits.
2. List 3 file limitations with examples.
- Redundancy: Dup SName.
- Inconsistency: Name mismatch.
- Isolation: No Roll link.
- Ex: Table 8.1/8.2.
3. Explain data redundancy.
- Dup data in files.
- Waste space, inconsistency.
- Ex: Guardian in STUDENT.
- Avoid via split tables.
4. What is DBMS? Give examples.
- Software for DB ops.
- Ex: MySQL, Oracle.
- Manages queries.
- Abstract view.
5. Define schema and instance.
- Schema: Design.
- Instance: Snapshot.
- Ex: Empty vs populated.
- Changes via ops.
6. Explain attribute and tuple.
- Attribute: Column.
- Tuple: Row.
- Ex: GName attr, Ahuja tuple.
- Relation = table.
7. What are 3 properties of relation?
- Unique attrs.
- Distinct tuples.
- Atomic values.
- Ex: No multi GPhone.
8. Differentiate degree vs cardinality.
- Degree: Cols (4).
- Cardinality: Rows (5).
- Ex: GUARDIAN Fig 8.4.
- Width vs length.
9. Define candidate key.
- Unique attr candidate.
- Ex: GUID, GPhone.
- For primary.
- Multiple possible.
10. What is foreign key? Example.
- Ref to another PK.
- Ex: Roll in ATTENDANCE.
- Links tables.
- NULL possible.
Part C: 4 Marks Questions (10 Qs - Medium-Long, Exactly 6 Lines Each)
1. Explain file system limitations (A-C).
- A: Access via programs only.
- B: Redundancy (dup data).
- C: Inconsistency (mismatch).
- Ex: SName in both files.
- Leads to errors.
- DBMS solves.
2. Describe file to DBMS conversion.
- Split STUDENT to GUARDIAN.
- Add GUID unique.
- Remove SName from ATTENDANCE.
- Link via FK.
- Ex: Tables 8.4-8.6.
- Reduces dup.
3. Explain relational model terms.
- Attribute: Col (GName).
- Tuple: Row.
- Domain: Values (ints).
- Degree: Cols.
- Cardinality: Rows.
- Fig 8.4 ex.
4. List 3 relation properties.
- Unique attr names.
- Distinct tuples.
- Atomic values, same domain.
- Ex: No multi phone.
- NULL for unknown.
- Seq immaterial.
5. Differentiate primary vs foreign key.
- Primary: Unique in table.
- Foreign: Ref to primary.
- Ex: GUID PK, Roll FK.
- Fig 8.5 arrows.
- FK NULL ok.
- Links relations.
6. What is composite key? Example.
- Multi-attr PK.
- No single unique.
- Ex: {Roll, Date} ATTENDANCE.
- Unique combo.
- Daily one entry.
- Prevents dup.
7. Explain DBMS key concepts (A-C).
- A: Schema design.
- B: Constraints (UNIQUE).
- C: Meta-data catalog.
- Ex: NOT NULL Roll.
- Ensures accuracy.
- Stored in dict.
8. Why use keys in DB?
- Unique tuples.
- Link tables.
- Avoid dup.
- Ex: Candidate to primary.
- Integrity.
- Retrieval easy.
9. Describe data isolation.
- No links between files.
- Separate programs.
- Ex: STUDENT/ATTENDANCE no Roll map.
- Hard integration.
- DBMS uses FK.
- Format diffs.
10. Role of NULL in relations.
- Unknown/non-applicable.
- Property 3 allows.
- Ex: No GPhone.
- Not in PK.
- FK possible.
- Flexibility.
Part D: 6 Marks Questions (10 Qs - Long, Exactly 8 Lines Each)
1. Justify: File system causes inconsistency; how DBMS avoids.
- Dup data mismatch.
- Ex: Name change in one file.
- Separate maintenance.
- DBMS: Single source, keys.
- Update once propagates.
- Ex: GUID update in GUARDIAN.
- Evidence: Limitations C.
- Centralized integrity.
2. Design STUDENTATTENDANCE schema; explain changes.
- STUDENT(Roll PK, SName, DOB, GUID FK).
- GUARDIAN(GUID PK, GName, GPhone, GAddress).
- ATTENDANCE({Date,Roll} PK, Status).
- Changes: Split guardian, add GUID.
- Remove SName dup.
- Ex: Tables 8.4-8.6.
- Fig 8.1 structure.
- Reduces redundancy.
3. Explain 3 relation properties with examples.
- 1: Unique attrs, seq immaterial.
- Ex: GName unique.
- 2: Distinct tuples, seq immaterial.
- Ex: No identical rows.
- 3: Same domain, atomic, NULL.
- Ex: GPhone 10 digits, indivisible.
- Fig 8.4 facts.
- Ensures order.
4. Differentiate candidate, primary, composite keys.
- Candidate: Any unique (GUID, Phone).
- Primary: Chosen candidate.
- Ex: GUID PK, Phone alternate.
- Composite: Multi (Roll+Date).
- No single unique.
- Ex: ATTENDANCE daily one.
- Table 8.7 schemas.
- Unique distinction.
5. Explain DBMS concepts: Schema, Constraints, Instance.
- Schema: Structure (tables, types).
- Ex: STUDENT fields.
- Constraints: Limits (UNIQUE Roll).
- Ex: NOT NULL.
- Instance: Data snapshot.
- Ex: Populated vs empty.
- Changes via insert/update.
- Catalog stores meta.
6. How does foreign key establish relations? Diagram.
- FK = ref PK.
- Ex: Roll FK in ATTENDANCE to STUDENT PK.
- Links data.
- Fig 8.5: Arrows from FK to PK.
- Primary: Master table.
- Referencing: Child.
- NULL if optional.
- Ensures integrity.
7. Analyze GUARDIAN relation (Fig 8.4).
- Degree: 4 attrs.
- Cardinality: 5 tuples.
- Flat: Single values.
- Ex: Amit row.
- Domain: Strings/ints.
- Properties: Distinct, atomic.
- PK: GUID.
- Used in STUDENT FK.
8. Why controlled sharing in DBMS? Limitations.
- File: Hard access control.
- Ex: Teacher update only.
- DBMS: User roles.
- Limits: Complexity, vulnerability.
- Central fail halts all.
- Ex: Read-only for staff.
- Backup costs.
- Balanced security.
9. DBMS vs File: Redundancy/Inconsistency examples.
- File: Dup guardian (Roll 3/5).
- Change one → inconsistent.
- Ex: Shah name diff.
- DBMS: Split, one entry.
- FK links.
- Update propagates.
- Table 8.1 vs 8.5.
- Saves space.
10. Relational model advantages; properties role.
- Linked tables, no dup.
- Ex: STUDENT-GUARDIAN via GUID.
- Properties: Ensure uniqueness/atomicity.
- No order dependence.
- Domain consistency.
- Ex: Fig 8.3 schema.
- 2025: Scalable to big data.
- Basis for SQL.
Tip: Include tables in ans; practice design. Additional 30 Qs: Variations on exercises, key scenarios.
Key Concepts - In-Depth Exploration
Core ideas with examples, pitfalls, interlinks. Expanded: All concepts with steps/examples/pitfalls for easy learning. Depth: Debates, analysis.
File Limitations
Steps: 1. Grow files, 2. Access hard, 3. Dup/inconsist. Ex: Table 8.1 dup. Pitfall: Manual updates miss. Interlink: To DBMS. Depth: A-F details.
DBMS
Steps: 1. Create DB, 2. Query/manipulate, 3. Abstract. Ex: MySQL. Pitfall: High cost. Interlink: Apps Table 8.3. Depth: Engine role.
Schema
Steps: 1. Define tables/constraints, 2. Store in catalog. Ex: STUDENT schema. Pitfall: Poor design = issues. Interlink: Instance. Depth: Logical arch.
Constraints
Steps: 1. Apply on create (UNIQUE), 2. Enforce integrity. Ex: NOT NULL DOB. Pitfall: Over-constrain slows. Interlink: Keys. Depth: Accuracy.
Relation
Steps: 1. Table with tuples/attrs, 2. Linked. Ex: GUARDIAN. Pitfall: No FK = isolation. Interlink: Model. Depth: Flat file.
Attribute/Tuple
Steps: 1. Col/row define entity. Ex: GPhone attr. Pitfall: Non-atomic violates. Interlink: Domain. Depth: Related values.
Degree/Cardinality
Steps: 1. Cols/rows count. Ex: 4/5 GUARDIAN. Pitfall: High cardinality slow queries. Interlink: Size. Depth: Dimensions.
Properties (3)
Steps: 1. Unique/distinct/atomic. Ex: No dup rows. Pitfall: Violate = invalid DB. Interlink: Keys. Depth: Relational rules.
Primary Key
Steps: 1. Choose candidate, 2. Unique ID. Ex: GUID. Pitfall: NULL in PK. Interlink: FK. Depth: No dups.
Foreign Key
Steps: 1. Ref PK, 2. Link tables. Ex: Roll FK. Pitfall: Orphaned records. Interlink: Integrity. Depth: Relationships.
Composite Key
Steps: 1. Combine attrs, 2. Unique set. Ex: Date+Roll. Pitfall: Partial match dups. Interlink: ATTENDANCE. Depth: Complex unique.
Redundancy
Steps: 1. Dup across files, 2. Waste. Ex: Guardian details. Pitfall: Update all. Interlink: Normalization. Depth: Inconsistency cause.
NULL
Steps: 1. Use for unknown, 2. Property 3. Ex: No address. Pitfall: Overuse confuses. Interlink: Constraints. Depth: Flexibility.
Referential Integrity (Advanced)
Steps: 1. FK must match PK, 2. Enforce via DBMS. Ex: Valid GUID. Pitfall: Cascade deletes. Interlink: FK. Depth: Valid links.
Normalization (Advanced)
Steps: 1. Split to reduce dup, 2. Forms (1NF-3NF). Ex: Split STUDENT. Pitfall: Over-normalize slow. Interlink: Design. Depth: Efficiency.
Advanced: ER models, ACID properties. Pitfalls: Keyless tables. Interlinks: To SQL Ch9. Real: Bank DB. Depth: 14 concepts details. Examples: Real tables. Graphs: Schema Fig 8.5. Errors: Wrong FK. Tips: Steps evidence; compare tables (file vs relation).
Table Examples & Schemas - From Text with Simple Explanations
Expanded with evidence, analysis; focus on schemas. Added variations for practice.
Example 1: STUDENT File (Table 8.1 - Redundancy)
Simple Explanation: Dup guardian (Shah).
| Roll | SName | SDateofBirth | GName | GPhone | GAddress |
|---|---|---|---|---|---|
| 3 | Taleem Shah | 2002-02-28 | Himanshu Shah | 9818184855 | 26/77, West Patel Nagar, Ahmedabad |
| 5 | Ali Shah | 2003-07-05 | Himanshu Shah | 9818184855 | 26/77, West Patel Nagar, Ahmedabad |
- Step 1: See dup GName/Phone.
- Step 2: Causes inconsistency.
- Step 3: Split to GUARDIAN.
- Simple Way: Use FK.
Example 2: ATTENDANCE (Table 8.2 - Isolation)
Simple Explanation: No link to STUDENT.
| Date | Roll | SName | Status |
|---|---|---|---|
| 2018-09-01 | 1 | Atharv Ahuja | P |
| 2018-09-01 | 3 | Taleem Shah | A |
- Step 1: Dup SName.
- Step 2: Separate programs.
- Step 3: Use Roll FK, drop SName.
- Simple Way: Relational link.
Example 3: STUDENT Schema (Table 8.4 - Post-DBMS)
Simple Explanation: With GUID FK.
| Roll | SName | SDateofBirth | GUID |
|---|---|---|---|
| 1 | Atharv Ahuja | 2003-05-15 | 444444444444 |
| 3 | Taleem Shah | 2002-02-28 | 101010101010 |
- Step 1: Unique Roll PK.
- Step 2: GUID FK to GUARDIAN.
- Step 3: No dup guardian.
- Simple Way: Integrity.
Example 4: GUARDIAN (Table 8.5 - Unique)
Simple Explanation: Single source (Degree 4, Cardinality 5).
| GUID | GName | GPhone | GAddress |
|---|---|---|---|
| 444444444444 | Amit Ahuja | 5711492685 | G-35, Ashok Vihar, Delhi |
| 101010101010 | Himanshu Shah | 9818184855 | 26/77, West Patel Nagar, Ahmedabad |
- Step 1: GUID PK.
- Step 2: Atomic values.
- Step 3: Distinct tuples.
- Simple Way: No redundancy.
Example 5: ATTENDANCE Composite PK (Table 8.6)
Simple Explanation: {Date, Roll} unique (2025 scalable).
| Date | Roll | Status |
|---|---|---|
| 2018-09-01 | 1 | P |
| 2018-09-02 | 1 | P |
- Step 1: No single unique.
- Step 2: Combo PK.
- Step 3: Roll FK to STUDENT.
- Simple Way: Daily records.
Example 6: Keys Schema (Fig 8.5 - Links)
Simple Explanation: FK arrows.
| Table | PK | FK |
|---|---|---|
| STUDENT | RollNumber | GUID |
| GUARDIAN | GUID | - |
| ATTENDANCE | {AttendanceDate, RollNumber} | RollNumber |
- Step 1: Define PK/FK.
- Step 2: Ensure matches.
- Step 3: Query across.
- Simple Way: Relations.
Tip: Draw schemas; troubleshoot (e.g., no PK dups). Added for keys, conversions.
Interactive Quiz - Master Database Concepts
10 MCQs in full sentences; 80%+ goal. Covers files, DBMS, relations, keys.
Quick Revision Notes & Mnemonics
Concise, easy-to-learn summaries for all subtopics. Structured in tables for quick scan: Key points, examples, mnemonics. Covers files, DBMS, model, keys. Bold key terms; short phrases for fast reading.
| Subtopic | Key Points | Examples | Mnemonics/Tips |
|---|---|---|---|
| File System |
|
Table 8.1 dup Shah. | ARIDDS (Access Redundancy Inconsistency Dependence Sharing Isolation). Tip: "Files Are Redundant Disasters" – Switch to DBMS. |
| DBMS |
|
MySQL, Fig 8.2 env. | CMAQ (Create Manage Abstract Query). Tip: "DBMS Manages Messy Files" – Central hub. |
| Key Concepts |
|
NOT NULL Roll. | SIM (Schema Instance Meta). Tip: "Schema Is Map, Instance Is Map Marked" – Structure vs data. |
| Relational Model |
|
Fig 8.4: Deg4 Card5. | ATDDC-UPDA (Attr Tuple Domain Deg Card Unique Props Distinct Atomic). Tip: "Relations Are Tuples of Attributes" – Table basics. |
| Keys |
|
GUID PK, Roll FK. | CPCF (Candidate Primary Composite Foreign). Tip: "Keys Connect Primary Candidates" – Link tables. |
| Redundancy/Inconsistency |
|
SName in two tables. | RI (Redundancy Inconsistency). Tip: "Redundant Inconsistency = Bad Design" – Normalize. |
Overall Tip: Use ARIDDS-CMAQ-SIM-ATDDC-UPDA-CPCF-RI for full scan (5 mins). Flashcards: Front (term), Back (points + mnemonic). Print table for wall revision. Covers 100% chapter – easy for exams!
Key Terms & Processes - All Key
Expanded table 30+ rows; quick ref. Added advanced (e.g., Normalization, Integrity).
| Term/Process | Description | Example | Usage |
|---|---|---|---|
| File System | Data containers | STUDENT.txt | Basic storage |
| DBMS | DB software | MySQL | Management |
| Database | Related data | StudentAttendance | Collection |
| Schema | Design blueprint | Table structures | Architecture |
| Constraint | Data limit | UNIQUE Roll | Integrity |
| Meta-data | Data about data | Catalog | Dictionary |
| Instance | Snapshot | Populated tables | State |
| Query | Info request | Find presents | Retrieval |
| Relation | Table | GUARDIAN | Storage |
| Attribute | Column | GName | Feature |
| Tuple | Row | Ahuja record | Entity |
| Domain | Values set | Integers Roll | Type |
| Degree | Attrs count | 4 GUARDIAN | Width |
| Cardinality | Tuples count | 5 GUARDIAN | Size |
| Primary Key | Unique ID | GUID | Distinction |
| Foreign Key | Ref PK | Roll ATTEND | Link |
| Candidate Key | Potential PK | GPhone | Alternative |
| Composite Key | Multi PK | {Date,Roll} | Combo |
| Redundancy | Dup data | Dup guardian | Waste |
| Inconsistency | Mismatch | Name diff | Error |
| Isolation | No links | Separate files | Hard integrate |
| Dependence | Struct change | Update programs | Rigid |
| NULL | Unknown | No phone | Flex |
| Insertion | Add data | New student | Manipulation |
| Deletion | Remove data | Leave school | Manipulation |
| Update | Modify data | Change phone | Manipulation |
| Engine | Core programs | Query handler | Backend |
| Normalization | Reduce dup | Split tables | Design |
| Referential Integrity | FK=PK | Valid GUID | Validity |
| Alternate Key | Unused candidate | GPhone | Backup |
| Domain | Value pool | 10-digit phone | Constraint |
| Atomic | Indivisible | Single phone | Property |
Tip: Examples memory; sort subtopic. Easy: Table scan. Added 10 rows depth.
Database Processes Step-by-Step
Step-by-step breakdowns of core processes, structured as full questions followed by detailed answers with steps. Visual descriptions for easy understanding; focus on actionable Q&A with examples from chapter.
Question 1: How to convert file system to DBMS as in school example?
- Step 1: Identify dups (guardian in STUDENT).
- Step 2: Split to GUARDIAN table with GUID PK.
- Step 3: Add GUID FK to STUDENT.
- Step 4: Drop SName from ATTENDANCE; use Roll FK.
- Step 5: Define schemas/constraints.
- Step 6: Populate (Tables 8.4-8.6).
Visual: Split arrow – STUDENT → STUDENT + GUARDIAN. Example: Shah one entry, linked.
Question 2: What steps define a relation like GUARDIAN (Fig 8.4)?
- Step 1: List attrs (GUID, GName, etc.).
- Step 2: Define domains (string/int).
- Step 3: Set PK (GUID UNIQUE).
- Step 4: Add tuples (rows).
- Step 5: Ensure properties (distinct, atomic).
- Step 6: Degree=4, Cardinality=5.
Visual: Build blocks – Attrs → Tuples → Properties check. Example: Amit row added.
Question 3: How to establish FK relation (Fig 8.5)?
- Step 1: Choose PK in master (GUID GUARDIAN).
- Step 2: Add same attr as FK in child (STUDENT).
- Step 3: Ensure FK values match PK or NULL.
- Step 4: Define constraint.
- Step 5: Query joins via FK.
- Step 6: Maintain integrity.
Visual: Arrow link – STUDENT GUID → GUARDIAN GUID. Example: Roll 1 links Ahuja.
Question 4: Process of data manipulation (insert example)?
- Step 1: New student joins.
- Step 2: Insert to GUARDIAN (new GUID).
- Step 3: Insert to STUDENT with GUID FK.
- Step 4: Check constraints (unique Roll).
- Step 5: Update instance.
- Step 6: Query to verify.
Visual: Add row – GUARDIAN first → STUDENT link. Example: Rivaan insert.
Question 5: How does DBMS handle query (Fig 8.2)?
- Step 1: User queries (teacher attendance).
- Step 2: DBMS processes via engine.
- Step 3: Access catalog/schema.
- Step 4: Retrieve from DB tables.
- Step 5: Return results.
- Step 6: Multiple users concurrent.
Visual: Flow arrows – Query → Engine → DB → Result. Example: Find presents via Roll.
Question 6: Steps to apply constraints in schema.
- Step 1: Create table.
- Step 2: Add NOT NULL/UNIQUE.
- Step 3: Ex: Roll UNIQUE NOT NULL.
- Step 4: Insert checks auto.
- Step 5: Violate → Error.
- Step 6: Store in meta-data.
Visual: Lock icons on cols – UNIQUE lock. Example: Dup Roll reject.
Tip: Treat as FAQ; apply to tables. Easy: Q → Steps + Visual. Full Q&A for exam-like practice.
