92 lines
5.0 KiB
Markdown
92 lines
5.0 KiB
Markdown
# Merise Methodology & Transformation Reference
|
|
|
|
This reference covers the formal Merise rules for constructing Conceptual Data Models (MCD) and translating them into Logical Data Models (MLD).
|
|
|
|
---
|
|
|
|
## 1. Merise Concepts
|
|
|
|
### 1.1 Entité (Entity)
|
|
An object, concept, or person with an independent existence in the business domain.
|
|
- Has a unique identifier (**Identifiant** / Primary Key candidate).
|
|
- Contains atomic properties (**Propriétés** / Attributes).
|
|
- In MLD: Becomes a relational table prefixed with `<DB_TRIGRAM>_`.
|
|
|
|
### 1.2 Association (Relationship)
|
|
A semantic link between two or more entities.
|
|
- May be binary (between 2 entities), ternary (3 entities), or reflexive (an entity linked to itself).
|
|
- May carry properties (e.g. `QUANTITY` in a `CONTAINS` association).
|
|
|
|
### 1.3 Cardinalités (Cardinalities)
|
|
Defined as a pair `(min, max)` for each entity participating in an association:
|
|
- `min`: Minimum number of times an entity instance can participate in the association (`0` or `1`).
|
|
- `max`: Maximum number of times an entity instance can participate in the association (`1` or `N`).
|
|
|
|
Common combinations:
|
|
- `(0,1)`: Optional, at most one
|
|
- `(1,1)`: Mandatory, exactly one
|
|
- `(0,N)`: Optional, zero to many
|
|
- `(1,N)`: Mandatory, at least one
|
|
|
|
---
|
|
|
|
## 2. MCD to MLD Transformation Rules
|
|
|
|
### Rule 1: One-to-Many Association (`(X,1)` ↔ `(X,N)`)
|
|
When one side has a maximum cardinality of `1` and the other side has a maximum cardinality of `N`:
|
|
1. **No new table** is created for the association.
|
|
2. The primary key of the `(X,N)` entity migrates into the table of the `(X,1)` entity as a **Foreign Key (FK)**.
|
|
3. Any attributes on the association migrate into the `(X,1)` table as well.
|
|
4. **Naming convention**: In the host table (`HOST`), the foreign key referencing `TARGET` is named:
|
|
`<HOST_TRIGRAM>_<TARGET_TRIGRAM>_<COLUMN_NAME>`
|
|
*Example*: `ECO_ORDER` (`ORD`) has FK `ORD_CUS_ID` referencing `ECO_CUSTOMER` (`CUS`).
|
|
|
|
### Rule 2: Many-to-Many Association (`(X,N)` ↔ `(X,N)`)
|
|
When both sides have a maximum cardinality of `N`:
|
|
1. **A new table is created** for the association.
|
|
2. The table name uses a meaningful functional name (e.g. `ECO_ORDER_ITEM`) or a concatenation of entity names (e.g. `ECO_ORDER_PRODUCT`).
|
|
3. The **Primary Key** is composite, consisting of the foreign keys referencing both participating entities:
|
|
- `(#ITE_ORD_ID, #ITE_PRO_ID)`
|
|
4. Any attributes of the association become columns in this junction table (e.g. `ITE_QUANTITY`, `ITE_UNIT_PRICE`).
|
|
|
|
### Rule 3: One-to-One Association (`(X,1)` ↔ `(X,1)`)
|
|
When both sides have a maximum cardinality of `1`:
|
|
- **Case A: `(1,1)` ↔ `(0,1)`**:
|
|
The primary key of the `(0,1)` entity migrates into the table of the `(1,1)` entity as an FK with a `UNIQUE` constraint.
|
|
- **Case B: `(0,1)` ↔ `(0,1)`**:
|
|
The primary key migrates into either table (whichever entity is created second or is functionally secondary) with a `UNIQUE` constraint.
|
|
- **Case C: `(1,1)` ↔ `(1,1)`**:
|
|
Usually indicates the two entities should be merged into a single table, unless there is a strong architectural reason for separation.
|
|
|
|
### Rule 4: Reflexive Association (Self-Referencing)
|
|
An association between an entity and itself (e.g. Employee has a Manager who is an Employee, or Category has a Parent Category):
|
|
1. **Reflexive `(0,1)` / `(1,1)` to `(0,N)`**:
|
|
- A foreign key column is added to the same table.
|
|
- Named: `<TBL_TRIGRAM>_<TBL_TRIGRAM>_<ROLE_NAME>_<COL>`
|
|
- *Example*: In `ECO_CATEGORY` (`CAT`), parent category FK: `CAT_CAT_PARENT_ID`.
|
|
- *Example*: In `COR_EMPLOYEE` (`EMP`), manager FK: `EMP_EMP_MANAGER_ID`.
|
|
2. **Reflexive `(0,N)` to `(0,N)`** (e.g. Product is composed of other Products - Bill of Materials):
|
|
- A junction table is created (e.g. `ECO_PRODUCT_COMPONENT`).
|
|
- Trigram `COM`: `COM_PRO_PARENT_ID` and `COM_PRO_CHILD_ID` forming the composite PK.
|
|
|
|
---
|
|
|
|
## 3. Normalization Rules (1NF, 2NF, 3NF)
|
|
|
|
Every relational model produced by this skill must satisfy **Third Normal Form (3NF)**:
|
|
|
|
### First Normal Form (1NF)
|
|
- Every table has a primary key.
|
|
- Every column contains only atomic (indivisible) scalar values (no CSV strings, no JSON objects as substitute for relational tables).
|
|
- No repeating groups or duplicate columns (e.g. `PHONE_1`, `PHONE_2` is invalid; use a separate phone table if multiple phones are supported).
|
|
|
|
### Second Normal Form (2NF)
|
|
- Must be in 1NF.
|
|
- Every non-key column must depend on the **entire** primary key (applies to composite primary keys in junction tables).
|
|
- *Example Violation*: In junction table `ECO_ORDER_ITEM` with PK `(ITE_ORD_ID, ITE_PRO_ID)`, having `ITE_PRODUCT_NAME` is invalid because the product name depends only on `PRO_ID`, not on `ORD_ID`.
|
|
|
|
### Third Normal Form (3NF)
|
|
- Must be in 2NF.
|
|
- No non-key column may depend on another non-key column (no transitive dependency).
|
|
- *Example Violation*: In `ECO_CUSTOMER`, having `CUS_CITY_NAME` and `CUS_CITY_POSTAL_CODE` where postal code determines city name. If postal code determines city, normalize into a separate `ECO_CITY` table or ensure direct dependency on customer address.
|