Relation DB.pptx a powerpoint presentation

Fundamentals of Database Systems
Georgian Technical University
Faculty of Informatics and Control Systems
Welcome to the course!
Professor Lili Petriashvili
Email: petriashvililili08@gtu.ge

Conceptual Data Modeling and Database Design. Data Modeling Using the Entity–
Relationship (ER) Model. Using High-Level Conceptual Data Models for Database
Design. Entity Types, Entity Sets, Attributes, and Keys. Relationship Types,
Relationship Sets, Roles, and Structural Constraints. Weak Entity Types. The Enhanced
Entity–Relationship (EER) Model. Subclasses, Superclasses, and Inheritance.
Specialization and Generalization. Constraints and Characteristics of
Specialization and Generalization Hierarchies. Modeling of UNION Types Using
Categories. Data Abstraction, Knowledge Representation, and Ontology Concepts.
Topic of the Second Lecture:

The most commonly used data types:
Data Type Description
INT Stores integer values. Typically used for whole numbers. Range: -
2,147,483,648 to 2,147,483,647.
BIGINT Stores larger integer values. Range: -9,223,372, to 9,223,372,036,
DECIMAL Stores fixed-point numbers.
NUMERIC Similar to DECIMAL, stores fixed-point numbers.
FLOAT Stores approximate floating-point numbers.
CHAR Stores fixed-length character data.
VARCHAR Stores variable-length character data
TEXT Stores large variable-length text data.
DATETIME Stores date and time values.
DATE Stores date values only.
TIME Stores time values only.
BIT Stores Boolean values (0 or 1).
BINARY Stores fixed-length binary data.
VARBINARY Stores variable-length binary data.

Data Modeling Using the Entity-Relationship (ER) Model is a
method for visually representing the structure and relationships
within a database. It uses entities (objects or concepts) and
relationships (associations between entities) to model real-world
data.
Key components:
1.Entities: Represent real-world objects, such as “Hotel" or “Customer.”
2.Attributes: Describe the properties of entities, such as a Hotel's name or a
Customer's email.
3. Relationships: Define associations between entities, like a "Customer"
making a "Reservation."
4. Primary Keys: Uniquely identify each entity instance, like “HotelID" or
“Customer ID."
5. Cardinality: Describes how many instances of one entity can be related to
another (e.g., one-to-many, many-to-many).

Conceptual Data Models
Conceptual Data Modeling and Database Design
Conceptual Data Modeling and
Database Design refers to the process
of creating a visual representation of the
structure and organization of data within
a system. This is a critical first step in
the development of databases, providing
a clear understanding of data
requirements and relationships before
moving on to more detailed design.

Logical Data Models
Logical data models build on the information captured at the conceptual
stage, defining entity types, data attributes, and the relationships that exist
between entities. They provide an indication of an organization’s current
capabilities, scope and limitations, and whether new technologies/processes
may be necessary.

Physical Data Model
A physical data model specifies how the data model will be built in the
database. It outlines all table structures, including column name, data
types, column constraints, primary key and foreign key with indexes to the
relevant table column, relationships between tables, stored procedures,
and views.
Each logical data model example is translated into a physical data model
schema. The first, which refers to an e-commerce use case, can be
transformed into the following:

Entity Types, Entity Sets, Attributes, and Keys in
Hotel Database Context
Entity Types
Entity types represent categories of objects, people, or concepts that have properties in
common. In a hotel management system, the main entity types might include:
• Hotel: The physical property offering accommodations
• Room: Individual units available for guests to stay in
• Guest: People who book and stay in the hotel
• Reservation: The booking information connecting guests to rooms
• Employee: Staff who work at the hotel
• Service: Additional offerings provided to guests
Entity types are the templates that define what data we track in our database.

Entity Sets
Using hotel example:
• The entity type "Room" defines the structure (what a room record contains)
• The entity set "Rooms" contains all specific room records: Room 101, Room 102, Suite 301, etc.
In a hotel with 200 rooms, the "Rooms" entity set would contain 200 individual room entities.
Attributes:
Attributes are the specific properties that describe each entity type:
1. Simple attributes: Basic, indivisible properties
1. Hotel: HotelID, Name, StarRating
2. Room: RoomNumber, Floor, DailyRate
2. Composite attributes: Properties that can be broken down
1. Address (Street, City, State, ZIP, Country)
2. GuestName (FirstName, LastName)
3. Single-valued attributes: Properties with one value per entity
1. Room: SquareFootage, MaximumOccupancy
4. Multi-valued attributes: Properties that can have multiple values
1. Room: Amenities (TV, Mini-bar, Safe, etc.)
2. Hotel: PhoneNumbers
5. Derived attributes: Calculated from other attributes
1. Reservation: TotalCost (calculated from DailyRate × NumberOfNights)
2. Guest: Age (derived from DateOfBirth)

Keys
Keys uniquely identify entities and establish relationships:
1. Super Key: Any attribute combination that uniquely identifies entities
1. For Room: {HotelID, RoomNumber, Floor, RoomType}
2. Candidate Key: Minimal super key with no redundant attributes
1. For Room: {HotelID, RoomNumber}
3. Primary Key: The chosen candidate key
1. Hotel: HotelID
2. Room: combination of HotelID and RoomNumber (composite primary key)
3. Guest: GuestID
4. Reservation: ReservationID
4. Foreign Key: References primary key in another entity set
1. Reservation has GuestID (references Guest)
2. Reservation has HotelID and RoomNumber (references Room)
5. Composite Key: Multiple attributes forming a key
1. Room's primary key: {HotelID, RoomNumber}
6. Alternate Key: Candidate keys not chosen as primary key
1. Guest might be uniquely identified by Email (alternate key)

Relationship Types, Relationship Sets, and Roles:
• Relationship Types: Define how entities are related to each other.
For example, in a Student-Course relationship, a student may enroll
in many courses, and each course can have many students.
• Relationship Sets: A collection of similar relationships. For
example, a set of all Student-Course enrollments is a relationship
set.
• Roles: Specify the function or role that an entity plays in a
relationship. In a Student-Course relationship, the role of a student
might be "Enrolled," and the role of a course might be "Offered."

Structural Constraints:
• Cardinality Constraints: These specify how many instances of one entity
can be related to instances of another entity. It can be one-to-one, one-to-
many, or many-to-many.
• Participation Constraints: These indicate whether all or only some entity
instances participate in a relationship. For example, a student might be
required to be enrolled in at least one course (total participation) or can
choose to enroll (partial participation).
1. Cardinality Constraints: These define how many instances of one entity can be
associated with instances of another entity. There are three main types:
 One-to-One (1:1): One instance of an entity relates to only one instance of
another entity.
 One-to-Many (1:N): One instance of an entity can be related to multiple
instances of another entity.
 Many-to-Many (M:N): Multiple instances of an entity can be related to multiple
instances of another entity.
2. Participation Constraints: These specify whether all or only some instances of an
entity must participate in a relationship. There are two types:
 Total Participation: Every instance of an entity must be involved in the
relationship (e.g., a student must be enrolled in at least one course).
 Partial Participation: Only some instances of an entity may participate in the
relationship (e.g., not all employees need to be assigned to a project).

Weak Entity Types:
 Weak Entities: These are entities that cannot be uniquely identified by their own attributes
alone. They depend on a strong or owner entity for identification. For example, a Dependent
entity might depend on an Employee entity to be uniquely identified (like the dependent’s
relationship to an employee).
 Identifying Relationship: A weak entity is connected to its owner entity through an identifying
relationship. This relationship helps the weak entity to gain a unique identifier from the strong
entity.
Weak Entities
Strong Entity

Enhanced Entity-Relationship (EER) Model
• EER Model
• The Enhanced Entity-Relationship (EER) model is an extension of the basic Entity-
Relationship (ER) model.
• It is used to represent more complex data and relationships in a database.
• The EER model incorporates advanced concepts such as subclasses, superclasses,
specialization, generalization, and categorization.
• Key Features of EER:
• Subclasses and Superclasses: EER allows us to model hierarchical relationships. A
superclass contains shared attributes of different subclasses.
• Specialization: This process allows an entity to be divided into specialized subgroups based
on certain characteristics.
• Generalization: Opposite of specialization, it involves combining entities into a higher-level
entity with common attributes.

Components of the Enhanced Entity-Relationship
(EER) Model
• Entities and Attributes:
• Entities: Objects or concepts in the database (e.g., Student, Course).
• Attributes: Properties that describe the entities (e.g., StudentID, CourseName).
• Relationships:
• EER supports one-to-many, many-to-many, and one-to-one relationships,
just like the standard ER model, but can also represent hierarchical
relationships between entities.
• Specialization and Generalization:
• Specialization: An entity is divided into more specific sub-entities. For example,
a Person entity could be specialized into Student and Faculty.
• Generalization: The opposite process, where multiple entities with similar
attributes are generalized into a higher-level entity.
• Categories:
• In EER, a category is a way to represent multiple types of entities that can
participate in a relationship, often seen in complex real-world scenarios.

Subclasses, Superclasses, and Inheritance
• Subclasses and Superclasses:
• Superclass: A higher-level entity that contains common attributes
for multiple subclasses. For example, a Vehicle entity might be a
superclass, with subclasses like Car, Truck, and Motorcycle.
• Subclass: A more specialized entity that inherits attributes from
its superclass. For example, Car inherits common attributes like
VehicleID, Model, and Year from the Vehicle superclass.
• Inheritance:
• Subclasses inherit both attributes and relationships from their
superclass. This allows for reusability and avoids redundancy.

Specialization and Generalization
• Specialization:
• The process of defining a more specific entity from a general entity.
For example, a Person entity can be specialized into Student,
Faculty, and Staff.
• Total Specialization: All instances of the superclass must be
classified into subclasses.
• Partial Specialization: Not all instances need to be classified into
subclasses.
• Generalization:
• The reverse process of specialization. It involves grouping entities that
share common attributes into a higher-level entity.
• Example: Student, Faculty, and Staff can be generalized into the
Person entity.

Constraints and Characteristics of Specialization and Generalization
Hierarchies
• Specialization Constraints:
• Disjointness Constraint: A subclass instance can only belong to one
subclass in a given hierarchy.
• Overlap Constraint: A subclass instance can belong to more than one
subclass in the hierarchy.
• Generalization Constraints:
• Total Participation: Every entity in a lower level must be included in the
higher-level entity.
• Partial Participation: Not all entities at the lower level must be included
in the higher-level entity.
• Inheritance in Hierarchies:
• Attributes are inherited from the superclass down to the subclasses,
making it easier to manage common attributes across different entities.

Modeling of UNION Types Using Categories and Data
Abstraction Concepts
• Modeling Union Types with Categories:
• Categories are used to model multiple entity types that share
relationships but have different characteristics. It is useful for
representing union types where an entity can belong to more than one
type.
• Example: A Vehicle might belong to either the Car or Truck category
based on its attributes.
• Data Abstraction:
• Data abstraction hides the complex reality while exposing only the
essential parts. In databases, it’s represented by separating the logical
view of data from the physical implementation.
• Knowledge Representation and Ontology:
• Ontology in databases represents knowledge about concepts and
entities, their relationships, and how they interact in the real world.
• It helps in knowledge sharing, reasoning, and understanding of complex
data relationships.

Schema Diagram for University Database

 How does the ER model help with data modeling and database design,
and what are its key components?
 What are the differences between specialization and generalization in the
EER model, and why are they important?
 How do weak entity types work, and how are they related to strong
entities in database design?
 What are structural constraints like cardinality and participation, and
how do they ensure data consistency in relationships?
Discussion Questions:

Relation DB.pptx a powerpoint presentation

More Related Content

Similar to Relation DB.pptx a powerpoint presentation (20)

Recently uploaded (20)

Relation DB.pptx a powerpoint presentation