Introduction to Database Management System

Introduction to Database Management Systems (DBMS)

• The idea of a “database” predates computers; examples include:
  • Looking up a word in a paper dictionary.
  • Searching a friend’s number in a printed telephone directory.
• Modern life is permeated by computerized databases:
  • Railway / airline ticketing, library catalogues, payroll, ATM transactions, etc.
  • Databases can store a variety of data types: text, images, audio, video.

Data vs. Information

• Data = raw, unprocessed facts.
  • May relate to people, places, events, things.
  • May appear as text, graphics, audio, video.
  • Examples: marks, weights, costs, product names, addresses, tax codes.
• Information = processed, organized, or summarized data that is meaningful.
  • Example: individual marks + roll numbers (data) → consolidated report card (information).
  • Correct information depends on accurate data.
• Illustration using daily temperature table:
  • Data (recorded temperatures) can be processed to find \text{max} / \text{min} day-night values.

Storing Data in Tabular Form (Example)

Databases & DBMS

• Database: an organized collection of logically related data items.
• DBMS (Database Management System): software that creates, stores, updates, deletes, retrieves, and secures data in a database.
  • Common DBMS examples: MS Access, LibreOffice / OpenOffice Base, Oracle, Ingres, MySQL.
  • Course text uses LibreOffice Base v6.4 for demonstrations.
• Analogy: phone book in a mobile = simple database; the Contacts app = DBMS layer.

Advantages of Using a DBMS

• Organised Storage → fast & accurate retrieval.
• Data Analysis → compute \text{MAX}, \text{MIN}, \text{AVG}, etc., efficiently.
• Data Sharing → “create once, use many times” across multiple applications.
• Minimal Data Redundancy → avoids unnecessary duplication.
• Data Consistency → single update reflects everywhere; less contradiction.
  • Scenario: Student "Ram Lal Kumar" → "Ram Kumar" change reflected in both Admission and Library tables automatically when tables are related.
• Increased Efficiency → well-indexed tables speed read/write/search operations.
• Increased Accuracy → lower redundancy + consistency → fewer errors.
• Increased Validity → define field-level constraints (e.g., \text{Fees} > 1000).
• Enhanced Security → passwords + encryption restrict unauthorised access.

Data Models (Structural Blueprints)

• Data model = formal description of how data is stored & related.
  • Specifies data items, relationships, and constraints.
• Three classical models:
  1. Hierarchical Model
  2. Network Model
  3. Relational Model (dominant today)

Hierarchical Data Model

• Tree-like structure; one-to-many parent→child links.
• Data stored as records (collection of fields).
• Example figure: Company "Likes Ltd." at root → child record sets for Personal Information & Project Information.

Network Data Model

• Inverted tree (many-to-many); multiple child records can point to multiple parents.
• Master record at bottom; branches hold inter-linked info.
• Example figure: Personal Information and Project Information connect to central "Likes Ltd." master.

Relational Data Model

• Proposed by E.F. Codd (1970).
• Organises data in tables (relations) of rows & columns.
• Tables are related through common fields (keys).
• Widely adopted in commercial DBMSs (SQL, MySQL, etc.).

Core Relational Terminology

• Entity: real-world object about which data is stored (e.g., Student).
• Attribute / Field / Column: property of an entity (e.g., Roll No.).
• Table (Relation): collection of logically related records.
• Record / Row: complete set of attribute values for one entity instance.
• Data Value: individual atomic value (numeric, text, alphanumeric).
• Primary Key (PK): unique identifier for each record.
  • Must be non-null & unique.
  • Single field or compound (composite key).
• Composite Key: PK formed by more than one column.
• Foreign Key (FK): field in one table that uniquely identifies a PK in another, establishing relationships.
• Candidate Key: any field(s) qualifying to become PK (unique + non-null).
• Alternate Key: candidate key not chosen as the PK.
• Relational Database: collection of related tables connected via PK–FK links.

Example Two-Table Relationship

1. Student Registration (PK = Enrollment No.)
2. Student Marks (PK = Roll No.; FK = Enrollment No.)

The FK allows joining marks to student biodata.

RDBMS Objects / Components

• Tables: store data (rows × columns).
• Forms: GUI screens for user-friendly data entry (text boxes, list boxes, radio buttons, etc.).
• Queries: questions posed to database; retrieve subset matching criteria.
  • Example filter: students with \text{Total Marks} > 50.
• Reports: formatted, printable presentations of query output (headings, grouping, totals).

Worked Scenario (Murugan at ABC School)

• Two tables: Admission & Library.
• Student requests name & address change.
  • Without DBMS: update must be done separately in both tables → prone to error.
  • With relational DBMS: change once; cascades to related tables → no redundancy / inconsistency.

Practice Table & Questions

• Likely Primary Key = Item No. (each value unique & non-null; natural identifier).
• Table has: 5 fields (columns) and 3 records (rows).

Ethical / Practical Considerations Noted

• Security & encryption protect sensitive data.
• Reducing redundancy improves storage efficiency and data integrity.
• Proper constraints enhance data validity, avoiding incorrect analytical conclusions.

Connections to Broader Concepts

• Relational model underpins SQL (Structured Query Language).
• Hierarchical concepts influenced early mainframe databases (e.g., IBM IMS).
• Network model’s many-to-many thinking informs modern graph databases.
• Concepts like PK, FK carry over to object-relational mapping (ORM) in software engineering.