BISDI FEB UNPAD - Pemrograman Komputer 2 - B - #12 - 3 Nov 2026

Summary

The lecture explains how to decide when a software project needs a database and how to build a solution from simple code toward a more structured system. The instructor emphasizes understanding the problem and its business rules before choosing technologies or asking AI to generate code.

Main Ideas and Lessons

Choose Tools Based on the Problem

Not every application needs a database, object-oriented programming (OOP), or a complex interface. First, analyze what the client or user needs, what data must be kept, and what can happen during normal use.

For example, a doctor-queue application likely needs to track patients and their queue status. A shop may need to track products, prices, stock, orders, and discounts. As requirements are added, complexity grows, so project scope and effort should be taken seriously.

Begin with Simple Data Structures, Then Add Complexity When Needed

Python lists and dictionaries can organize product data and support basic operations such as displaying products, searching, and calculating inventory value. A simple procedural program may be sufficient for a small example or a basic shopping-cart demonstration.

As a system gains customers, transactions, discounts, stock checks, or other rules, separating responsibilities becomes more useful.

Model the Business Rules Accurately

A transaction should not be completed if a required product is out of stock. Discounts, customer loyalty, payment methods, and inventory replenishment should be implemented only when they are part of the actual requirements.

Avoid assumptions—whether made by a developer or by AI—such as assuming every product is always available or every customer has the same circumstances. Build a basic working solution first, then add and test features incrementally. The instructor compares overengineering to using a flamethrower to kill a mosquito: it may work, but it is inefficient and costly.

Use OOP When the System’s Objects and Responsibilities Justify It

Possible objects in a sales system include products, customers, orders, and order items. A product can hold information such as its name, price, and stock, along with relevant behavior. An order can connect a customer with the products and quantities purchased.

Classes should have clear roles. For example:

• A product handles product-related information and behavior.
• A customer may have customer-specific rules, such as loyalty discounts.
• An order records a transaction and its contents.

The lecture also introduces the idea that an object can contain other objects, as when an order includes order items and products. Different types of customers, such as regular and VIP customers, can have different discount rules. Abstract classes are useful when a general concept needs more specific implementations, but the instructor cautions that abstraction is not necessary for every small project.

Database Concepts and Workflow

Relational Database Design

A database may contain separate tables for customers, products, orders, and order items. Separating data can reduce repeated information, but too many separate tables can make queries more complicated and costly. Design should balance redundancy against query complexity.

• A primary key uniquely identifies a row in a table. The lecture recommends a unique ID, often an auto-incrementing number.
• A foreign key links a row to a related row in another table—for example, an order’s customer ID links it to a customer.
• An order-items table can connect orders and products, including the relevant quantities.

Names or emails are generally less suitable than IDs for table relationships. Composite keys are possible but can be more cumbersome.

CRUD with Python and SQLite

The instructor demonstrates using Python’s SQLite module to create a database and perform the four basic database operations:

1. Create: Connect to the database, create a table if it does not exist, and insert records.
2. Read: Use a SELECT query and fetch the results; filter or sort them with conditions such as WHERE and ORDER BY.
3. Update: Change selected values, such as a product’s price, for rows matching a condition.
4. Delete: Remove a selected record, such as a product that is no longer available.

The example product table includes fields such as product ID, name, price, and stock. The instructor also demonstrates joining customer and order data using their keys.

Relate Database Tables to OOP Responsibilities

A class and a database table are related design concepts, but they are not the same thing. The lecture demonstrates a layered structure:

• Product class: Represents a product and its behavior.
• Product repository: Handles database operations such as inserting, reading, updating, and deleting product records.
• Product service: Enforces business rules, such as requiring a name and category and preventing negative prices or stock.
• GUI: Provides the interface and calls the appropriate service functions when a user clicks buttons.

This separation makes it easier to change the interface, database handling, or business rules without mixing them together.

Use Pandas When It Helps with Data Processing

SQLite results can be loaded into a Pandas DataFrame. DataFrames make it easier to sort, reshape, modify, summarize, and analyze data—for example, by calculating stock totals by category or preparing data for visualization and data science.

AI and Development Practice

The instructor does not forbid using AI tools. The key expectation is that students understand and verify the code they use.

AI can make assumptions, produce unnecessary complexity, or generate code that does not match the project’s real rules. A recommended approach is to make a small version first, test it, and add features step by step. Students should inspect AI-generated results, correct problems, and avoid repeatedly prompting without understanding what needs to change.

The instructor compares AI’s impact to the arrival of computers: using a tool effectively can improve speed and productivity, but users still need the underlying skills to operate it well.

Examples and Applications Discussed

• A doctor-queue system and a shop or shopping-cart application illustrate how requirements determine whether a database and customer records are needed.
• A coffee-shop system could analyze sales to estimate busy periods and popular menu items, then help plan inventory. Simple statistics may be enough; a more advanced AI model is not automatically necessary.
• Other possible projects include a personal expense tracker, inventory dashboard, Telegram-based data-entry tool, or content-performance analyzer.

Course and Project Planning

The instructor discusses a forthcoming final project, with the format and coordination still to be confirmed. Students may be able to work individually or in groups; a student coordinator is asked to poll the class.

Individual projects may be simpler and more flexible. Group projects should have appropriately broader scope and clearly divided responsibilities. Students are reminded to use the existing Google Classroom and Colab materials and save their work.

Speakers and Sources Featured

• Instructor/lecturer: Leads the class, explains the programming and database concepts, and discusses project expectations.
• Students: Participate with questions or brief responses. Naya/Kanaya is addressed about coordinating a class poll; Noval is invited to respond about prior database study.
• Tools and technologies mentioned: Python, SQLite, SQL, Pandas, JDBC/Java, Google Colab, and AI assistants including ChatGPT, Gemini, and Claude. These are discussed as examples or development tools, not as additional speakers.