Information management matters because data must be collected, saved, and used well to support decisions and planning.

Importance:

• Improved decision-making
• Enhanced efficiency
• Better data security
• Regulatory compliance
• Competitive advantage

• Pre-digital era: paper ledgers/files/books; slow retrieval; mostly manual processing.
• Early digital era (1960s-1980s): databases + electronic records; DBMS begins managing structured data.
• Networked systems (1990s-2000s): internet + enterprise apps; ERP/CRM become common.
• Big data & cloud (2010s-present): huge volumes; analytics, AI, cloud storage/processing; more automation and real-time processing.
• Future trends: blockchain, IoT, edge computing.

The outline lists five roles:

• Supporting decision-making
• Enhancing business operations
• Facilitating collaboration and communication
• Ensuring data security and compliance
• Improving customer relationship management

Ethical themes

• Privacy protection - handle personal/sensitive data responsibly.
• Data accuracy & integrity - accurate, reliable, not manipulated.
• Access control - only authorized people.
• Transparency - clear about collection, storage, use.
• Intellectual property rights - respect copyright, patents, trademarks.

Legal examples named

• General Data Protection Regulation (GDPR)
• Data Privacy Act of the Philippines (RA 10173)
• Freedom of Information (FOI) laws
• Cybercrime laws

Consequences of non-compliance

• Financial penalties and legal action
• Damage to an organization’s reputation
• Loss of customer trust and business opportunities

A database environment works like a coordinated team: hardware, software, data, and users work together to store, manage, and retrieve information. Building a DB is an organized process: requirements → design → implementation → testing → maintenance (like building a house).

Core components

• Hardware - servers, storage, network gear hosting the DB.
• Software - the DBMS (e.g., MySQL, Oracle, PostgreSQL).
• Data - raw facts stored in structured form.
• Users - end-users, DBAs, developers.

Courses often add procedures - documented methods/policies (standards, SDLC steps) for building and operating databases. The outline stresses a structured methodology for development across the early units.

• Data - raw facts with no meaning alone (e.g., “100”, “John”).
• Information - processed data with meaning (e.g., “John has 100 points”).
• Metadata - data about data (tables, relationships, limits).
• Database - systematic collection of connected electronic data.
• DBMS - software for storage, retrieval, security.
• Schema - logical structure: tables, relationships, constraints.
• Query - SQL request to read/update data.

Organizations once kept separate files per application. Common problems:

• Data redundancy & inconsistency - duplicates disagree.
• Limited data sharing - one app’s file is hard for others to use.
• Data isolation - siloed files complicate retrieval/updates.
• Security issues - hard to secure many separate files.
• Change difficulty - updates touch many files → error risk.

Instead of isolated files, data sits in a centralized database managed by a DBMS.

Key features

• Data abstraction - conceptual/logical views vs. physical storage.
• Integrity & consistency - constraints + normalization.
• Data sharing - many users/programs, same DB.
• Improved security - access control + authentication.
• Reduced redundancy - less duplicate data.

Costs & risks

• High initial costs (software, hardware, training)
• Complexity (needs skilled people)
• Performance issues if design is poor
• Security vulnerabilities if access rules are weak

Practical steps

1. Identify requirements
2. Design a data model (ER diagrams)
3. Choose DBMS (SQL vs NoSQL as needed)
4. Normalize tables
5. Implement SQL
6. Secure the database
7. Monitor and optimize

Industries using databases: finance, healthcare, e-commerce, education, social media, big data & AI.

The SDLC section maps phases to DB work:

• Planning - needs, scope, feasibility, preliminary data analysis.
• Analysis - collect data needs; entities/relationships; enterprise data model.
• Design - logical design (ERD + normalization); physical schema; security.
• Implementation - SQL build/populate; servers; integrity & backups.
• Testing - functional/performance; integrity; security tests.
• Deployment & maintenance - go-live; monitor/optimize; updates/backups.

Prototyping: build an early version, refine with feedback, then finalize. Helps reduce misunderstanding, fix design issues early, improve UX, and support training.

Agile: flexible, collaborative, iterative; incremental DB changes; frequent testing; close collaboration among DBAs, developers, and users; refactoring + CI; databases stay aligned with changing needs.

• Database designers - structure, tables, constraints.
• Database developers - SQL, procedures, DB logic.
• DBAs - security, backups, performance, availability.
• System analysts - requirements ↔ technology alignment.
• Application developers - integrate DB with apps.
• End users - use systems; give feedback.
• Data engineers - migration, transformation, integration.

Separates external views, conceptual/logical design, and physical storage.

Why use it?

• Data independence - physical changes don’t break logical/user views.
• Security - external schema can limit sensitive fields by role.
• Easier maintenance - change layers independently when possible.
• Scalability - structured approach for large apps.

• Presentation - UI (web/mobile/desktop).
• Application - business rules, APIs, middleware, web servers.
• Data - DB servers (SQL or NoSQL), consistency & security.

Benefits named: performance split, security (no direct DB access from clients), scalable layers, easier maintenance.

Entity-Relationship model is a conceptual model of organizational data: entities store data; attributes describe entities; relationships link entities (e.g., “Customer places an order”).

Business rules are standards/policies for how data is created, maintained, and used. Modeling rules supports integrity and alignment with policy.

Good data naming: consistent standards, clarity, uniqueness. Data definitions specify meaning, data types, allowed values, and usage context.

Logical design arranges data for efficiency and consistency without fixing physical storage details.

Codd’s relational model (1970) uses tables (relations): rows (tuples), columns (attributes).

• Keys - primary keys identify rows; foreign keys link tables.
• Integrity constraints - keep data valid and consistent.
• CRUD - Create, Read, Update, Delete via SQL.

Enhanced ER (EER) extends ER with subclasses/superclasses, specialization/generalization, and aggregation.

Normalization organizes tables to reduce redundancy and improve integrity by splitting tables and defining relationships.

The course activity asks you to move unnormalized designs to at least 3NF (Third Normal Form). In practice: 1NF removes repeating groups; 2NF removes partial dependencies on part of a key; 3NF removes transitive dependencies on non-key attributes - standard textbook steps your activity refers to when proving normalization.