Module 1 - Bussiness and techincal views

Goal of the special lesson #

1. Understand how to translate business problems into technical problems.
2. Introduction to data normalization.
3. As you work through this lesson, we recommend that you try implementing it on the instance of your choice. The goal is to understand how to create an application that meets the business requirements, rather than completing the implementation.
4. Create an interface for the application library.
5. Implement the backend logic.

Business requirements #

The goal is to create an app to manage a small library. The app should:

• Track borrowing and returning of book copies: track which books are borrowed, returned, and by whom.
• Allow librarians to view:
  • Author, customer, and book category details.
  • The number of available copies of each book.
  • Borrowing/return history with customer and book details and any late fees.
• Enable Customer Interaction: Allow librarians to easily borrow and return books for customers.
• Manage Book Details: Identify books by title, author, and category. Track each book’s unique copy with a barcode, showing availability status.

Technical requirements #

The app will include:

• Data Model & Views:

  • Search View: Display entities in a table, with options to filter, add, edit, delete, and perform custom actions.
  • Edit View: Allow adding or editing entities.

• Core System Features:

  • Track book instances and update stock in the book entity.
  • Check book instances availability after borrowing or returning.
  • Calculate penalties if a book is returned after the term (7 days).
  • Display book history with details like date, book, author, category, history type, and late return fees.

Business Problems to Technical Problems #

To convert business problems into a data model, we identify key entities (e.g., “author”, “book”) and their relationships. For example, authors write multiple books, and customers borrow books. These relationships are translated into tables and normalized to reduce redundancy and improve data integrity.

Data normalization #

Normalization is the process of organizing data to reduce redundancy and improve data integrity. It is typically achieved through a series of steps known as normal forms, each of which addresses specific types of redundancy and dependency issues. These are the first three normal forms:

First Normal Form (1NF) Each table must have atomic (indivisible) values, and there should be no repeating groups or arrays in any column.

Issue Fixed by 1NF:

• If a customer would have multiple phone numbers stored in a single cell as a comma-separated list, it would violates 1NF.
• The solution is to break it into separate rows or use a related table (e.g., “customer_phone”).

Example:

• Customer Table
  • The “name”, “phone”, “email”, and “total_tax” columns are atomic.
  • There are no repeating groups or arrays.

Second Normal Form (2NF)

• The table must first be in 1NF and all non-key attributes must be fully dependent on the entire primary key (i.e., no partial dependency).

Issue Fixed by 2NF:

• If a table has a composite primary key and a non-key attribute depends on only part of the key, it violates 2NF.
• The solution is to split the table into smaller ones, ensuring each non-key attribute depends on the whole composite key.

Example:

• Book_Category Table
  • Composite primary key: “id_book” and “id_category”.
  • No non-key attributes depend only on part of the composite key.

Third Normal Form (3NF)

• The table must first be in 2NF and there should be no transitive dependencies (i.e., non-key attributes should depend only on the primary key, not on other non-key attributes).

Issue Fixed by 3NF:

• If a non-key attribute depends on another non-key attribute, it violates 3NF.
• The solution is to move such attributes to related tables.

Example:

• Book_History Table
  • “id_book_history_type” is a foreign key referring to “book_history_type”.
  • Attributes like “name”, “label”, and “uuid” depend only on “id_book_history_type”, not on other non-key attributes.

What’s Next? #

In the next module, we will learn how to design our database structure based on these principles.