Distinguishable Data Object, ออกสอบ

Part 1: Business Requirement Analysis

BUSINESS RULES AND CONSTRAINTS

Database Concept - Three Schema Architecture

Three Schema Levels:

1. External Level (Human Understandable)
   • External Schema for End Users
   • External/Conceptual Mapping
2. Conceptual Level
   • Conceptual Schema
   • Conceptual/Internal Mapping
3. Internal Level (Machine Processable)
   • Internal Schema
   • Stored Database

Analogy: Think of this like a building with three floors - the top floor is where users interact (human-friendly), the middle floor translates between user needs and technical requirements, and the bottom floor is where the actual data storage happens (machine-friendly).

Principle Concept for Database Analysis, Design, and Implementation

From Real-world Business Domain to Implementation:

• Business Requirements → Business Rules & Constraints
• Data Object Declaration → Data Objects
• Conceptual Design (ERD) → Entities
• Internal/Relational Design → Relations
• Physical Implementation → Tables

Analogy: This is like building a house - you start with what the family needs (business requirements), create a blueprint (data model), then build the actual structure (database tables).

Business Requirements Analysis

The Problem:

• Organizations get complicated as they evolve
• Simply automating the business results in complex, restrictive and inflexible systems

The Solution:

• Top-down analysis of business requirements represents what's truly required
• Essential: End-users' needs or requirements
• Enterprise: The whole business, or specific business functions/operations

What is a Business Rule?

Definition: A business rule is a brief, precise, and unambiguous description of business requirements, end-users' needs according to the policy, procedure, or principle within a specific organization.

• Key Characteristics:
  • Must be rendered in writing
  • Updated to reflect any change in the organization's operational environment
  • Used to define entities, attributes, relationships, and constraints
• Examples:
  • A customer can generate many invoices
  • An invoice is generated by only one customer
  • A training session cannot be scheduled for more than 20 employees

Business Rules Templates

Template #1: Relationship Template

$\boxed{\text{Data Object (Noun)} + \text{Relationship (Verb)} + \text{Data Object (Noun)}}$
Example: A Student attends many Classes.

Template #2: Container Template

$\boxed{\text{Data Object (Noun)} + \text{Container (Verb)} + \text{Data Properties/Attributes (Noun)}}$
Example: A Student comprises Student ID, Name, many EMails.

Business Requirement Analysis Methods

Forward and Backward Analysis

Forward Analysis:

• Analyze on the main object using ==Active voice==
• Example: A Student enrolls for many courses

Backward Analysis:

• Analyze on the indirect object using ==Passive voice==
• Example: A course is enrolled by many students

Purpose: These two ways of analysis aim to formulate the "Bi-Directional relationship on data objects"

Note: This analysis can apply for Template #1 only.

How to Formulate Rule Sentences

Sentence Structure:

• Forward (FW) Sentence: A Subject + Verb (Active Voice) + Object(s)
• Backward (BW) Sentence: A Subject + Verb (Passive Voice) + Object

Derivation Rules:

• BW Subject ← derived from FW Object
• BW Object ← derived from FW Subject

Example Analysis:

• FW: A member can buy many product items (1:M)
• BW: A product item can be bought by only one member (1:1)

Rule Sentence Analysis:
$\boxed{\text{FW (1:M) vs BW (1:1)} \rightarrow \text{Final conclusion is (1:M)}}$
Final Business Rule Sentence: A member can buy many product items.

Business Rule Sentence Analysis Types

Type 1: One-To-One (1:1)

$\boxed{\text{Forward (1:1) vs Backward (1:1)} \rightarrow \text{Final conclusion is (1:1)}}$

Type 2: One-To-Many (1:M)

$\boxed{\text{Forward (1:1) vs Backward (1:M)} \rightarrow \text{Final conclusion is (1:M)}}$
OR
$\boxed{\text{Forward (1:M) vs Backward (1:1)} \rightarrow \text{Final conclusion is (1:M)}}$

Type 3: Many-To-Many (M:N)

$\boxed{\text{Forward (1:M) vs Backward (1:M)} \rightarrow \text{Final conclusion is (M:N)}}$

Business Constraints

Definition: Represent the conditions or restrictions of business data observed from business activities.

Examples:

• A student must enroll for 5 subjects, if the accumulated GPA is below 2.00
• A borrower must return the books within 7 days
• A taxi driver can rent a car for 7 days but he can pay the rental fee for only 6 days

Example: University Domain Business Rules

"A university consists of a number of departments. Each department offers several courses. A number of modules make up each course. Students enroll in a particular course and take modules towards the completion of that course. Each module is taught by a lecturer from the appropriate department, and each lecturer tutors a group of students."

From Requirements to Data Model

Business requirements covering both business rules and business constraints provide all components of data model:

• Data object → defines Entity
• Attributes
• Relations
• Etc.

Purpose: Analyzing business rules is to declare the data transactions obtained from business functions (both master and transactional data records).

Part 2: Data Modeling

FROM BUSINESS RULES TO A DATA MODEL

Business Rules as Building Blocks

Flow:
Business Requirements → Business Rules and Constraints → Data Objects + Relationships → Data Model

Analogy: Business rules are like LEGO instructions - they tell you which pieces (data objects) to use and how to connect them (relationships) to build your final structure (data model).

Transforming Business Rules to Data Model

Key Principle:
$\boxed{\text{Noun} \rightarrow \text{Entity in the data model}}$
$\boxed{\text{Verb (active or passive voices) associating nouns} \rightarrow \text{Relationship among entities}}$
General Rules:

• Nouns translate to be entities
• Verbs translate to be relationships among entities
• Relationships are bi-directional

Examples:

• "A customer may generate many invoices"

  • customer (Entity) → generate (Relationship) → invoices (Entity)

• "A university consists of a number of departments"

  • university (Entity) → consists (Relationship) → departments (Entity)

Note: Use Template #1 from the business rules templates.

DATA MODELING AND DATA MODELS

Data Modeling Definition

Data Modeling: Process of creating a specific data model for a determined problem domain.

Database Design: Focuses on how the database structure will be used to store and manage end-user data.

Key Point: Data modeling is the first step (or process) to design and develop database system.

Analogy: Data modeling is like creating an architectural blueprint before building a house - you need to plan the structure before you start construction.

What is a Data Model?

Definition: Data model is a set of concepts that can be used to describe and represent the structure of data in a database.

Purpose: A DATA MODEL is a conceptual tool used to provide data abstraction by hiding details of data storage from the users.

Data Model represents:

• DATA
• DATA RELATIONSHIP
• DATA SEMANTICS
• DATA CONSTRAINTS
• TRANSFORMATIONS

Data Model = Blueprint

Key Concepts:

• Data model is the overview of the data = House blueprint is the overview of a house
• They represent the conceptualization of business data objects

Analogy: Just like you wouldn't build a house without blueprints, you shouldn't build a database without a data model. The data model shows the "floor plan" of your data.

Data Model Basic Building Blocks

Four Main Components:

1. Entities

• Represents a particular type of object in the real world
• They're "distinguishable"

2. Attributes

• A characteristic of an entity

3. Relationships

• An association among entities

4. Constraints

• A restriction placed on the data

Analogy: Think of building blocks like LEGO pieces - entities are the main blocks, attributes are the details on each block, relationships are how blocks connect, and constraints are the rules about which connections are allowed.

Entity

Definition: Anything (a person, a place, a thing, or an event) about which data are to be collected and stored.

Key Characteristics:

• Represents a particular type of object in the real world
• They're "distinguishable"
• Each entity occurrence is unique and distinct

Two Main Categories:

1. Tangible or Physical Objects

• Examples: customers, products

2. Intangible or Logical Objects (Abstractions)

• Examples: flight routes, musical concerts

Example:

• CUSTOMER entity: John Smith, Peter Cook

Distinguishable Data Objects

Definition: A "distinguishable data object" refers to a data object that can be uniquely identified and differentiated from other data objects within a given context.

Examples of Distinction:

Student vs Alumni

Shared Schema:

• FullName
• Birthdate
• Address

Distinguished Schema:

• Student: Year of Study, Probation Status
• Alumni: Year of Graduation, Work Experience

Other Examples:

• Truck vs Bus
• Customer vs Member

Analogy: Think of identical twins - they share many characteristics (shared schema) but have unique identifiers and some different traits (distinguished schema) that make them distinguishable.

Attribute

Definition: Characteristic of an entity.

Example - CUSTOMER entity attributes:

• Customer last name
• Customer first name
• Customer phone
• Customer address
• Customer credit limit

Question for Practice: How about CAR entity? What attributes would it have?

Analogy: Attributes are like the details on an ID card - they describe the specific characteristics that make each entity unique and identifiable.

Relationship

Definition: An association among entities.

Example: Relationship between customers and agents:

• An agent can serve many customers
• Each customer may be served by one agent

Three Types of Relationships

Type 1: One-to-One (1:1 or 1..1)

• Each of the stores is managed by a single employee
• Each store manager, who is an employee, manages only a single store

Type 2: One-to-Many (1:M or 1..*)

• A painter paints many different paintings, but each one of them is painted by only one painter

Type 3: Many-to-Many (M:N or ..)

• An employee may learn many job skills, and each job skill may be learned by many employees

Important Note: Relationships are BIDIRECTIONAL

How to Determine Relationship Types

Example 1: One-to-One

• FW Sentence: A student can hold only one student card (1:1)
• BW Sentence: A student card can be held by only one student (1:1)
• Analysis: FW (1:1) vs BW (1:1) → Final conclusion is One-to-One

Example 2: One-to-Many

• FW Sentence: A student can apply for only one faculty (1:1)
• BW Sentence: A faculty can be applied by many students (1:M)
• Analysis: FW (1:1) vs BW (1:M) → Final conclusion is One-to-Many

Example 3: Many-to-Many

• FW Sentence: A student can enroll many subjects (1:M)
• BW Sentence: A subject can be enrolled by many students (1:M)
• Analysis: FW (1:M) vs BW (1:M) → Final conclusion is Many-to-Many

Reference: Refer to slides on pages 10-12 for detailed analysis method.

Analogy: Think of relationships like different types of dances - some are solo (1:1), some are one person leading many (1:M), and some are group dances where everyone interacts with everyone (M:N).

Key Formulas and Rules Summary

Business Rule Analysis:

$\boxed{\text{FW Cardinality vs BW Cardinality} \rightarrow \text{Final Relationship Type}}$

Data Model Transformation:

$\boxed{\text{Nouns} \rightarrow \text{Entities}}$
$\boxed{\text{Verbs} \rightarrow \text{Relationships}}$

Sentence Templates:

$\boxed{\text{Entity} + \text{Relationship} + \text{Entity}}$
$\boxed{\text{Entity} + \text{Contains} + \text{Attributes}}$