Homework 4 – Kastriot Sejdiji

Unique identifier -> UID

A UID that is a single attribute -> Simple key

A UID that is a combination of attributes -> Composite key

A UID that does not occur in the natural world but is created for identification purposes in a
system -> Surrogate key

One of several UIDs that could identify something -> Candidate key

A candidate UID that is the primary identifier of something -> Primary key

A candidate UID that also identifies something,but is not the primary UID -> Alternate key

STORE: b
ACCOUNT & COMPANY: c
RACER: d
BOAT: a

2. Library Member with Multiple Candidate UIDs:

A scenario where a Library Member might need multiple candidate UIDs is when members
often use alternative identifiers, such as their membership card number and email address.

• Membership Card Number: This could be a primary unique identifier issued by the
library system, making it easy to track each member's library activities.
• Email Address: Useful as an alternative UID because many people remember their email
addresses better than their membership numbers. It’s convenient for the library to
locate members who may forget or misplace their membership cards.

Having multiple candidate UIDs allows flexibility in the search process and improves user
experience. For example, a member could be identified by email during online book renewals
or inquiries without needing to know their card number.

3. Identifying Entities with Appropriate UIDs:

Here are some suggested UIDs and attributes for each entity:
 • a. City:
 UID: City name + State/Province
 Additional attributes: Population, region code, area, and postal codes.
• b. Contact Person for a Customer: o UID: Contact person’s email or Contact ID (unique
identifier created in the system).
o Additional attributes: First name, last name, phone number, customer relationship
(such as “account manager”), and address.

• c. Train:
 UID: Train ID (unique number assigned to each train).
 Additional attributes: Train name, route number, operator, and capacity.
• d. Road:
 UID: Road name + City or Road ID (a unique identifier if there are common road
names).
 Additional attributes: Length, type (highway, residential, etc.), start and end
points, and maintenance authority.
• e. Financial Transaction (Transfer Funds):
 UID: Transaction ID (system-generated unique number for each transaction).
 Additional attributes: Amount, date, sender account, receiver account,
transaction type, and status.

• f. Award (Movies):
 UID: Award name + Year
 Additional attributes: Category (e.g., Best Actor, Best Picture), nominee list,
winner, and organization.

• g. Painting:
 UID: Painting ID or Title + Artist (as titles can be reused but are often unique by
artist).
 Additional attributes: Artist, year created, medium (oil, watercolor, etc.),
dimensions, and location (e.g., gallery or museum).

4. Issue with National Identification System:

• One significant issue with a national identification system is privacy and security. A
national ID system centralizes personal information, making it vulnerable to data
breaches. If compromised, it could expose sensitive information, leading to identity
theft or misuse of personal data.
 • Point of View: A secure system is essential, including advanced encryption and strict
access controls. However, individuals should have the right to control who accesses
their information, and the system should limit the amount of personal data stored to
reduce risks in case of a breach.

5. Relationship in the Video Store System

Entities and UIDs:

1. Movie:
 UID: Movie ID (unique identifier for each title).
 Attributes: Title, category (e.g., comedy, drama), and star actors (e.g., John Wayne,
Katherine Hepburn).

2. Disk:
 UID: Disk Number (unique for each physical DVD disk).
 Attributes: Format (HD or Blu-ray), movie ID (which movie it belongs to), and copy
number (in case there are multiple copies of a single movie).

3. Actor:
 UID: Actor ID or Birth Name (since birth names are unique and often the most
permanent identifier for actors).
 Attributes: Real birth name, date of birth, and movies they starred in.

4. Customer:
 UID: Membership Number (unique identifier for each club member).
 Attributes: First name, last name, phone number, address, and credit status.

5. Rental (to track the M relationship between Customer and Disk):

 UID: Rental ID (unique for each rental record).
 Attributes: Customer ID, disk number, rental date, and due date.

Resolving the M

Relationships:

• Customer-Disk Relationship (Rental Entity): Since customers can rent multiple DVDs at a
time and each DVD can be rented by multiple customers over time, we need a Rental entity
to handle the many-to-many relationship between Customer and Disk. This entity tracks
each instance of a rental.

• Movie-Actor Relationship: To track the movies that specific actors have starred in, a
• Movie_Actor junction entity could be used:
 Movie_Actor:
▪ UID: Combination of Movie ID and Actor ID
▪ Attributes: Role or character name, date of appearance (if needed).

6-2: Normalization and First Normal Form Practice Activities

The outcome of the first step of database normalization. 1NF eliminates repeating groups
by putting each into a separate table and connecting them with a 1:M relationship->First
Normal Form(1NF).
A series of steps followed to obtain a database design that allows for efficient access and
storage of data in a relational database. These steps reduce data redundancy and the
chances of data becoming inconsistent.-> Normalization

1. When checking a database model for First Normal Form (1NF), you are ensuring that:
- Each table has a primary key that uniquely identifies each row.

- All data is atomic, meaning that each field contains only one value per row
(no repeating groups or arrays within a single column).

- There are no repeating groups or multi-valued attributes within any table.

In other words, you are looking for tables that might have fields containing lists, arrays, or
sets of values and restructuring those tables so that each value is in its own row,
making the data more organized and reducing redundancy.

2. The rule of 1NF in the normalization process is:

- Eliminate repeating groups and ensure atomicity: Each column should contain
only one value per row, and there should be no repeating groups or arrays within a
column.

- Ensure unique rows: Every table must have a primary key that uniquely identifies each row.
3. Let’s check each Entity-Relationship Diagram (ERD) to see if it meets the requirements for
First Normal Form (1NF)

a. BUS Entity

- Attributes: `route number`, `capacity`, `driver`, `passenger`

- Issue: The `passenger` attribute suggests a repeating group, as each bus can
have multiple passengers.

To Correct:

- Remove `passenger` from the `BUS` entity and create a separate

BUS_PASSENGER relationship table to handle the 1:M relationship.

- The new structure would look like:

BUS

- `route number` (Primary Key)

- `capacity`

- `d

river`

BUS_PAS

SENGER

- `route number` (Foreign Key referencing BUS)

- `passenger` (could be a Passenger ID or similar unique identifier for each passenger)

b. DORMITORY and CAMPUS Entities

- Attributes for DORMITORY: `number`, `address`, `resident`

- Attributes for CAMPUS: `id`, `name`

- Issue: The `resident` attribute in the `DORMITORY` entity implies multiple values (repeating
 group) if a dormitory has more than one

resident. To Correct:

- Remove `resident` from `DORMITORY` and create a new DORMITORY_RESIDENT table.

- The new structure would look like:

DORMITORY

- `number` (Primary Key)

- `address

DORMITORY_RE

SIDENT

- `dormitory number` (Foreign Key referencing DORMITORY)

- `resident` (could be a Resident ID or a unique identifier for each resident)

c. STUDENT Entity

- Attributes: `id`, `first name`, `last name`

- Issue: There is no issue here, as each attribute contains only

a single value. Conclusion:

- The STUDENT entity is already in 1NF. No changes are necessary.

6-3: Second Normal Form Practice Activities

The outcome of the second step of database normalization -> Second Normal Form (2NF)

1. The given Entity-Relationship Diagram (ERD) suggests that the UID (Unique
Identifier) of a library book includes both its BOOK number and SHELF number. To
check if it follows the rules of Second Normal Form (2NF), we need to verify the
following:
Correction to Bring the ERD to 2NF:
To correct this, we can split the entities as follows:

1. BOOK (entity):

- Primary Key: `BOOK number`

- Attributes: `title`, `author`

2. BOOK_SHELF (junction table for the relationship between BOOK and SHELF):

- Primary Key: Composite key of `BOOK number` and `SHELF number`

- Attributes: `shelf size`

3. SHELF (entity):

- Primary Key: `SHELF number`

Let's review each question in the image to determine whether the Entity-Relationship
Diagrams (ERDs) comply with Second Normal Form (2NF) and, if needed, suggest corrections.

2. Class Enrollment ERD

The `ENROLLMENT` entity is the intersection (or join) table for the many-to-many (M:N)
relationship between `STUDENT` and `CLASS`.

- Primary Key: In the `ENROLLMENT` table, the primary key would likely be a
composite key made up of the `STUDENT` number and `CLASS` id.

- Attributes: `grade` and `room` are attributes in the

`ENROLLMENT` entity. 2NF Compliance Check:

In 2NF, all non-key attributes must depend on the entire primary key, not on a part of it. Since
`grade` and `room` are attributes of `ENROLLMENT`, they should depend on both the
`STUDENT` and `CLASS` to comply with 2NF.

- Analysis:
 - `grade` is likely specific to a student's performance in a particular class, so
it depends on both `STUDENT number` and `CLASS id`, which satisfies 2NF.

- `room`, however, may only depend on the `CLASS id` and not on the
`STUDENT number`, which would be a partial dependency and violate 2NF.

Correction:

To comply with 2NF, move `room` to the `CLASS` entity, as it only depends on `CLASS id`
and not on the `ENROLLMENT` composite key. After this adjustment, `ENROLLMENT`
will only have `grade` as a non-key attribute, which fully depends on both components
of the composite key.

3. Store and

Shopping Mall ERD

Correction:
To bring this ERD into 2NF, move `store specialty` to the `STORE` entity, as it depends only on
`STORE number`. After this change, `STORE LISTING` will only have `location in mall`
as a non- key attribute, which depends on the composite key of `STORE number` and
`SHOPPING MALL number`, ensuring 2NF compliance.

6-4-Third Normal Form Practice Activities:

Objectives
• Identify transitive dependencies in a data model
• Define the rule of Third Normal Form in the normalization process
• Examine a non-normalized entity and determine which rule, or rules of
normalization are being violated
• Apply the rule of Third Normal Form to resolve a violation in the model

The form of database normalization where all non-key fields are dependent on the key, the
whole key, and nothing but the key.->Third Normal Form(3nf)
A condition that exists when any attribute in an entity is dependent upon any other non-
UID attribute in that entity.->Transitive dependency

1. Identify the transitive dependency in the model below. State which attributes
violate Third Normal Form
Product
# Number
o Model
o Store Name
o Store Address
To bring this model into 3NF, you can create a separate STORE entity with store name as the
key and store address as an attribute. The PRODUCT entity would then reference store
name as a oreign key, removing the transitive dependency and satisfying 3NF.

2. Define the rule of Third Normal Form.

The rule of Third Normal Form (3NF) states that no non-UID attribute can be dependent on
another non UID attribute.

4. 4. Yes, there are transitive dependencies in the model. The attributes involved are:
• Agent and Agent Commission (through agent).
• Team and Team Coach (through team).

5.
Privacy Concerns:
A national ID card could potentially store sensitive personal information, such as
addresses, biometric data, or financial records. This raises concerns about privacy
violations if the information is accessed or misused by unauthorized parties. The more
detailed the card, the more vulnerable it becomes to data breaches or identity theft.

Problems a National ID Card Could Solve:

It could streamline government services, from healthcare and social benefits to tax
collection and voting, by providing a reliable way to verify identity. This could result
in faster processing times and reduced administrative errors.

DNA Mapping as a National ID:

In my opinion, DNA mapping could be a useful tool in very specific, limited contexts, such
as forensic investigations or highly secure environments. However, it is unlikely to
become a
practical or ethical substitute for a national ID card due to the serious privacy, ethical, and
social issues it would raise. The risks of government overreach, discrimination, and the loss of
personal autonomy make DNA a controversial and potentially harmful choice for a national ID.
Instead, a balance between security and privacy, with appropriate safeguards in place, would
be crucial for any identification system.
7-2: Hierarchies and Recursive Relationships Practice Activities

Recursive relationship A relationship between an entity and itself.->Recursive relationship

Hierarchical relationship A series of relationships that reflect entities organized into successive
levels.->Hiearchical relationship

1. Hierarchical Structure
In the hierarchical ER diagram, we will use separate entities for each level in the structure, with
each level connected by a relationship representing the hierarchical organization of regions,
districts, territories, and areas.

Entities and Relationships:

• Region: Represents the four main sales regions. Each region has a unique region_code.
• District: Represents the subdivisions within each region. Each district has a unique
district_code and is associated with a specific region.
• Territory: Represents the subdivisions within each district. Each territory has a
unique territory_code and is associated with a specific district.
• Sales Area: Represents subdivisions within each territory. Each sales area has a unique
sales_area_code and is associated with a specific territory.

Sales Personnel:

• Salesperson: Each salesperson is responsible for one or more sales areas and has
attributes like employee_id and sales_quota.
• Sales Manager: Each sales manager is responsible for one or more districts and has
attributes like employee_id.
• Sales Director: Each sales director is responsible for one or more regions and has
attributes like employee_id.

Relationships:

• Region to District: A one-to-many relationship, as each region contains multiple

districts.
• District to Territory: A one-to-many relationship, as each district contains multiple
territories.
• Territory to Sales Area: A one-to-many relationship, as each territory contains
multiple
sales areas.
 • Sales Area to Salesperson: A one-to-many relationship, as each sales area is assigned
to a single salesperson, but a salesperson may oversee multiple areas.
• District to Sales Manager: A one-to-many relationship, as each district is managed by
a single sales manager, but a manager may oversee multiple districts.
• Region to Sales Director: A one-to-many relationship, as each region is managed by a
single sales director, but a director may oversee multiple regions.

Diagram Structure:
• Region → District → Territory → Sales Area (hierarchical structure)
• Salesperson, Sales Manager, and Sales Director entities are associated with Sales
Area, District, and Region entities, respectively.

2. Recursive Structure
In the recursive ER diagram, we’ll use a recursive relationship to represent the hierarchical
structure within a single entity. The entities will include Sales Unit and Sales Personnel.

Entities:
• Sales Unit: This entity will represent each hierarchical level (region, district, territory,
and sales area) using a recursive relationship. Each Sales Unit has attributes such as
unit_type (indicating if it is a region, district, territory, or sales area), unit_code, and
a self- referencing foreign key parent_unit_code that points to the parent unit (e.g.,
a district’s parent would be a region).
• Sales Personnel: This entity represents all sales employees, with each individual
having attributes such as employee_id, role (salesperson, manager, or director), and
sales_quota (for salespeople only).

Relationships:

• Sales Unit to Sales Unit (Recursive): A recursive relationship that links each sales
unit to its parent sales unit. This allows each level of the hierarchy (regions, districts,
territories, and sales areas) to be represented within a single Sales Unit entity.
• Sales Unit to Sales Personnel: This relationship links each Sales Unit to the Sales
Personnel responsible for it. Each sales area will be associated with one salesperson,
each district with one sales manager, and each region with one sales director.

Diagram Structure:
• Sales Unit with a self-referencing relationship to represent the
hierarchy (regions > districts > territories > sales areas).
• Sales Personnel with a relationship to Sales Unit based on the level they manage.