Database Assignment

Student Name

Course

Tutor

Date
Question 1

(a) . The current plan for the GRAND SLAM relation displays a few potential change

irregularities:

Update Anomalies: If any data about a competition (like the scene, dates, or surface)

transforms, we would have to refresh different columns for every event of that

competition. This builds the gamble of irregularities or mistakes, particularly

assuming the update is missed in certain columns. Likewise, if any data about a player

(like their nation) transforms, we would have to refresh different lines for every event

of that player winning a competition.

Insertion Anomalies: Assuming another competition is added to the data set, yet no

player from a specific nation partakes in it, we can't embed that competition without

disregarding element trustworthiness. Similarly, in the event that another player wins

a competition however their nation isn't yet addressed in the data set, we can't embed

the player's data without disregarding element respectability.

Deletion Anomalies: Assuming that we erase a column addressing a competition

where just a single player from their nation partook, we lose data about that country's

support in the competition. Essentially, assuming we erase a line addressing a player

who was the main victor from their country, we lose data about that country's progress

in the competition.

These abnormalities show that the ongoing plan isn't as expected standardized and

could prompt information irregularities, overt repetitiveness, and loss of data

respectability. To resolve these issues, the information base plan should be changed

and standardized to basically the Third Normal Form (3NF)

(b) .In the GRAND SLAM relation, a candidate key is an exceptional mix of traits that

can extraordinarily distinguish each tuple (column) in the connection. Subsequent to

investigating the information, the applicant key(s) for this connection could be

{Tournament, Year, Occasion, Winner}. This blend is novel since it indicates a

specific competition, its year, the occasion type (e.g., Men's singles, Ladies' singles),

and the victor. No two lines have similar mix of these properties.

Normal Form: The typical type of a connection demonstrates the degree of

standardization it has gone through to dispose of information overt repetitiveness and

reliance issues. First Normal Form (1NF) in light of the fact that it contains nuclear

qualities in every cell, and there are no rehashing gatherings. In any case, it may not

be in higher typical structures, (for example, 2NF or 3NF) because of expected overt

repetitiveness and reliance issues. For instance, on the off chance that a player wins

different competitions around the same time and occasion type, their data (like nation)

would be copied across various lines.

Reasoning:

The applicant key {Tournament, Year, Occasion, Winner} exceptionally recognizes

each tuple in the connection. The connection is possible in 1NF because of nuclear

qualities however may not be in higher ordinary structures because of overt

repetitiveness and reliance issues, for example, copied player data for different

competition wins. This examination demonstrates that while the connection is in 1NF,

it might require further standardization to kill overt repetitiveness and reliance issues

and accomplish higher typical structures, for example, 2NF or 3NF.

(c) To convert the GRAND SLAM relation to a set of relations in at least the Third

Normal Form (3NF), there is need to identify functional dependencies and split the

data into smaller, non-redundant relations.

TournamentDetails:

Attributes: Tournament, Year, Venue, Dates, Location, Surface

Primary Key: Tournament, Year

No foreign keys

PlayerDetails:

Attributes: Winner, Country

Primary Key: Winner

No foreign keys

EventDetails:

Attributes: Event, Surface

Primary Key: Event

No foreign keys

TournamentEvent:

Attributes: Tournament, Year, Event

Primary Key: Tournament, Year, Event

Foreign Keys: (Tournament, Year) references TournamentDetails(Tournament, Year),

Event references EventDetails(Event)

TournamentWinner:

Attributes: Tournament, Year, Winner

Primary Key: Tournament, Year, Winner

Foreign Keys: (Tournament, Year) references TournamentDetails(Tournament, Year),

Winner references PlayerDetails(Winner)

Each relation is now in at least 3NF, and the adjustments above eliminated

redundancy and ensured data integrity by properly defining primary keys and foreign

keys.

(d).To make sense of how the new plan resolves the issues distinguished in (a) and

safeguards all the data in the first plan, we should recap the issues recognized and

afterward examine how they are settled in the new plan:

Issues recognized in the first plan:

Update Peculiarities: There might be irregularities on the off chance that a

competition or champ's subtleties should be refreshed. Cancellation Peculiarities:

Erasing a competition or victor's subtleties might bring about loss of related data.

Addition Oddities: Fragmented information passages or hardships in embedding new

information without abusing limitations.

How the new plan resolves these issues:

Update Inconsistencies: By parting the first connection into different relations, each

with its own essential key, update oddities are limited. For instance, in the new plan,

the Competition connection has an essential key made out of Competition and Year,

while the Player connection has Victor as its essential key. Along these lines,

refreshing competition subtleties or champ data should be possible autonomously

without influencing one another.

Erasure Peculiarities: Likewise, the gamble of cancellation oddities is relieved by

separating the first connection into more modest, related relations. Every connection

is planned with its own essential key, lessening the opportunity to accidentally erase

related data. For example, erasing a competition section in the Competition

connection won't influence the Player connection as well as the other way around.
Inclusion Irregularities: The new plan guarantees that embedding new information is

direct and disregards no requirements. Every connection is intended to catch explicit

data without overt repetitiveness, considering simple addition of new information

without the gamble of deficient passages. In general, the new plan saves all the data

present in the first plan while tending to the distinguished standardization issues. It

guarantees information honesty, limits overt repetitiveness, and gives a construction

that permits to proficient information the board and control.

Question 2

To make an entity-relationship diagram (ERD) for the Western Highlands Zoo data

set, Initially recognize the primary substances and their connections in view of the

gave querying necessities and contextual investigation depiction. Then, at that point,

list and make sense of any presumptions made in making the information model. At

long last, guarantee the ERD incorporates properties, essential and unfamiliar keys,

and uses crow's feet documentation.

Entities:

Animal

Animal Type

Class

Region

Enclosure

Zone

Keeper

Note

Attributes:
Animal: AnimalID (PK), Name, Gender, DateOfBirth, PlaceOfBirth, ChildFriendly

Animal Type: TypeID (PK), CommonName, ScientificName, Description, Diet,

ConservationStatus

Class: ClassID (PK), ClassName

Region: RegionID (PK), RegionName

Enclosure: EnclosureID (PK), EnclosureName

Zone: ZoneID (PK), ZoneName

Keeper: KeeperID (PK), Name, DateOfBirth, Address, ContactPhoneNumber,

NextOfKin, NextOfKinContactNumber

Note: NoteID (PK), AnimalID (FK), Note, Date

Relationships:

Animal - AnimalType (Many-to-One):

An animal belongs to an animal type. An animal type can have many animals.

AnimalType - Class (Many-to-One):

An animal type belongs to a class. A class can have many animal types.

AnimalType - Region (Many-to-One):

An animal type comes from a region. A region can have many animal types.

Enclosure - Zone (Many-to-One):

An enclosure belongs to a zone. A zone can have many enclosures.

Enclosure - Animal (One-to-Many):

An enclosure can contain multiple animals. Each animal belongs to one enclosure.

Keeper - Animal (Many-to-Many):

A keeper looks after multiple animals, and an animal can be looked after by multiple

keepers.

Keeper - Zone (Many-to-One):

A keeper works in a particular zone. A zone can have many keepers.

Class - Keeper (One-to-Many):

Each class of animals has one head keeper who supervises the relevant keepers.

Animal - Note (One-to-Many):

An animal can have multiple notes. Each note is associated with one animal.

Assumptions:

 Every animal type has a place with just a single class.

 Every animal type starts from just a single locale.

 Every enclosure can house different animal types, and a animal type can be

housed in numerous fenced in areas.

 Every keeper is alloted to something like one animal type.

 Each class has precisely one head keeper.

 Notes are intended for individual animals.

This ERD configuration considers adaptable querying and announcing, empowering

the zoo to actually examine their business and plan for what's in store
ERD DIAGRAM

Reference

https://perthzoo.wa.gov.au/animal/koala