DESCRIPTION :$-$

We will be creating a database system for the federal court system known as

QUECOURT, which has locations across all $50$ states in the United States, as part of our project

for the Court System Database System $($Quecourt$).$ We will give a description of the project and

screenshots of the platform on which we will be working for the Part $1$ of the project, which has

some essential needs.

DESIGN :$-$

Entities, Relationships, Entity Analysis, and a few other requirements are covered in this

project description.

MANDATORY REQUIREMENTS :$-$

$$ ENTITIES $-$ Court Building, Employee, Judge, Party, Lawyer, Case, Case Event and

Threat Incident.

$$ COURT BUILDING $-$ The building's ID $($which we may use as the main key$),$ address

$($which contains all relevant information about the address$),$ hearing room information,

detention facilities, build date, and other building$-$related information are its

characteristics.

$$ EMPLOYEE $-$ The following are the employee's attributes: employee ID$,$ employee

name, department and record, education, certifications, and criminal history.

$$ JUDGE $-$ JudgeName $($first$,$ middle, and last name$),$ Appointment Date$($s$),$ Court

Building ID $($we may use this for a Foreign Key$),$ Judge Department, Judge Experience

$($or$)$ Record, and JudgeID $($we view this as the main key$)$ are some of the qualities for the

judge.

$$ PARTY $-$ Party Name, Party Address, Party Mail, Party Contact Information, Party ID

$($which we regard as the fundamental key$),$ Party ID for the Lawyer,

$$ LAWYER $-$ characteristics for a lawyer are LawyerName $($first$,$ middle, and last name$),$

Specialty, and LawyerID $($which we regard as the main key$).$

$$ CASE $-$ Case characteristics include CaseBuilding ID $($which we may use as a foreign

key$),$ CaseType, CaseDescription, and CaseID $($which we regard as the main key$).$

$$ CASE EVENT $-$ Event ID $($ we consider this as Primary Key$),$ Case ID $($We can use it as

foreign key reference$),$ Case Event Type, Case Event Description.

$$ THREAT INCIDENT $-$ Incident ID $($we consider this primary key$),$ Date of Incident,

Incident Description, Parties Involved.

RELATIONSHIPS :$-$

$1)$ Court Building $($ one to many$)$ :$-$ The court building relationship might be viewed as $"1$

to Many."

$2)$ Hearing Room $($one to many$)$ :$-$ There might be several different kinds of hearing rooms

in one structure.

$3)$ Judge $($one to many$)$ :$-$ Every courthouse may house several judges.

$4)$ Case $($many to many$)$ :$-$ A case can be involving multiple parties such as plaintiffs,

defendants, witnesses

$5)$ Party $($ many to many $)$ :$-$ A party can be represented by one lawyer or more than one

lawyer

$6)$ Employee $($one to many $)$:$-$ Each court building has multiple employees working

$7)$ Case Event $($one to many$)$ :$-$ Each case has various events related to them

$8)$ Threat Incident $($many to many$)$ :$-$ an incident can have many parties

ENTITY ANALYSIS :$-$

This entity analysis shows that each and every entity that has been specified has a primary key

associated with it that allows access to its data. The connections that are described are based on

cardinality constraints.

We might also go ahead and add a few additional properties in order to meet certain standards.

ADDITIONAL REQUIREMENTS :$-$

Some of these, such as Case Status, Document Management, Scheduling, and Security,

are things we may consider or presume would be additional project requirements.

I WANT A PROPER E$-$R DIAGRAM BASED ON THE PROJECT DESCRIPTION ABOVE AND THEN I WANT THE TRANSFORMATION OF THAT E$-$R DIAGRAM INTO RELATIONS.