Database

Understanding how to model databases using ER diagrams is critical for effective data design.
The primary theory involves adding the primary key from a strong entity as a foreign key in related entities.

Recognize that many students may not have hands-on experience in designing a database.
Relying on theoretical knowledge is essential in this case.
Practical exercises can help understand the theoretical components of database design.

A suggested approach to database design involves starting with strong entities.
- Consider the entities that exist on the peripheries, which are often easier to identify.
- Examples include Country, Furniture, Appliances, Heating Methods, Special Features, Property Types, etc.
When creating instances for these strong entities, it usually requires understanding their relationships.

Strong entities are foundational and can serve as nodes from which other relationships flow.
  - Instances can be created for strong entities such as:
    - Furniture: e.g., chairs, tables
    - Property types: houses, apartments
Once instances for strong entities are identified, they can be connected to other entities to visualize the relationships.
For example, to connect a piece of furniture to a specific room:
  - Furnishing Process Example:
    - Create instances for furniture (e.g., Chair, ID 1; Table, ID 2)
    - Associate this furniture with rooms by first creating room instances.

Creating entities must be dependent on the existence of other related entities.
  - For instance:
    - Before associating furniture with a room, the Room entity must exist, as well as the Property entity which entails its Address.
    - The Address must comprise components like street and city.
Hierarchical dependencies must be observed:
- Example of Dependency Chain: Property → Owner → Address → City → Street.

Proposed steps when creating instances:
  1. Start with strong entities and their attributes before moving on to weaker entities.
  2. Always create values for non-primary key attributes first.
  3. After filling non-key attributes, assign values to primary keys to ensure valid instances.

Instance: Represents a unique occurrence of an entity.
- Related to programming:
- In a class context, creating an instance means generating an object from a class.
Relates directly to real-world representations (e.g., a residential property).

Presentation of relationships in diagrams must be clear to avoid confusion.
- Annotations must accurately reflect the nature of relationships, ensuring correctness.
Conversion and mapping of real-world concepts into database design:
- Need to specify attributes accurately.

Various types of relationships can exist, primarily categorized as:
  - Unary Relationships: Self-relations within the same entity
  - Binary Relationships: Most common, interlinking two entities
  - Ternary Relationships: Connecting three distinct entities
  - Example: Room associated with Furniture and Property might be a ternary relationship in certain models.

Understanding potential problems such as the Fan Trap:
  - Caused by misrepresentation of relationships, leading to ambiguity in data retrieval.
  - An example involving streets and postal codes illustrates how relationships can complicate the model.
    - A street can have multiple postal codes and vice versa, requiring careful mapping.

Committing to proper modeling helps to avoid anomalies when designing the database:
- Anomalies can arise from incorrect assignments in primary keys.
Avoid unnecessary associations by establishing clear entity relationships to maintain integrity.

Different approaches can be applied based on data availability:
- Top-Down Approach: Used when designing a new system based on clear requirements.
- Bottom-Up Approach: Applied when transforming existing data structures into a database schema requiring normalization processes.

Continued focus on the iterative process of database design and the importance of visualization.
Ensuring the clarity in identifying strong and weak entities, as well as the defined relationships, will lead to a successful database construction.
Upcoming discussions will shift towards logical data design aspects and normalization practices in subsequent lessons.