Database Design Project 1

DATABASE DESIGN PROJECT

Student’s Name

Institution
 Database Design Project 2

Introduction

This report aims to analyse Blue Mountains College database that stores data and information

about a teaching process. As concept mapped, the teaching process involves interactions

between key entities; these are, the students, Lecturers, staff, along with the employees. Other

entities that are also equally essential in the database include courses, classes, departments,

faculties, college and the rooms in which the teaching occurs. In analysing the entities as well

as the attributes and any other relevant aspect of the database, assumptions will be made and

thus there may be assumptions on the entities that need to be allocated to this database in

addition to the ones that are clearly given by the case study as well as for the attributes there

will be assumptions as to those that need to be part of the database. This paper has two

sections; the first section discusses the conceptual model and the second section describes the

logical model of the teaching process.

Part One: Conceptual Model

1. Identification of Entities

In relational databases, entities are easily identified because they form the main building

blocks. Database entity refers to time, unit, person, place, object, or anything about which

data is captured and stored in the form of tables, properties, or workflow (Riggs et al. 2019).

Although tables and workflows are optional for database entity, properties are considered

essential since entity cannot exist without properties. In the context of relational databases,

properties imply attributes thus entities must possess attributes. In the case of the Blue

Mountains College database, attributes are defined as follows:

I. Education – Education ID, Education-Type

II. Online – Online ID, Degree-Type

III. Face to Face – Number of Students

 Database Design Project 3

IV. Building- Building-ID, Building Location, Building Name, Building ID.

V. Room- Room-ID, Room Type, Room ID.

VI. Class- Class-ID, Class Time, Class ID.

VII. Student- Student-ID, Student first_name, Student last_name, Student ID, Email.

VIII. Course- Course-ID, Course-Description, Course Title, Course-ID.

IX. Department- Department-ID, Department Name, Department ID.

X. Faculty- Faculty-ID, Faculty Name, Faculty ID.

XI. Lecturer – Lecturer ID, Lecturer Code, Lecturer Rank, Lecturer Specialty, Employee-

ID.

XII. Admin- Admin-ID, Admin position.

XIII. Staff- Staff-ID, Staff-Level, Employee-ID.

2. Identification of entity subtypes and supertypes

Entity supertypes are generic entities that are associated with a single or multiple subtype

such that the entity supertype contains similar characteristics while the entity subtypes

contain inimitable attributes for every particualar entity subtype (Al-Masree, 2015). An entity

supertype, on the other hand, refers to an entity type that is related to one or more subtypes

whereby it possesses shared attributes of its subtypes. Following this description, an entity

subtype can be defined as the entity contained in an entity subgroup and has shared attributes

from their particular entity supertype. It is important to note that the attributes found in the

subgroup mentioned above differ from those in other groups.

Inheritance is another key component in entity subtypes and supertypes and can be defined as

that which determines the specific subtype where the occurrence of the supertype will be

related (Harrington, 2016). With regards to the Blue Mountains College database, some entity

subtypes and supertypes are identified as follows:

 Database Design Project 4

I. Employee Entity- This is an example of a supertype entity and has more than one

subtype. These subtypes are Lecturer entity, admin entity, and staff entity. The

Employee supertype entity also has shared attributes for its subtypes such as,

Employee First Name, Employee Last Name, Employee ID, and Hire Date attributes.

II. Faculty Entity- This is another example of supertype that has one subtype, the

Department entity and has the Faculty ID as a common attribute.

III. Department Entity- Comprises of the student subtype and the course subtype. The

common attribute shared is the Department ID.

IV. Class Entity- This supertype has the enrolment subtype and shared the Class ID

attribute.

3. Relationship between Entities and their Cardinalities

In the context of relational databases, cardinality can be defined as one data aspect being

relative to the other data aspect. Cardinalities (both maximum and minimum) also are

represented for both directions of the relationship and are placed in parentheses with the

minimum cardinality on the left and the maximum cardinality on the right. Concerning this

case study, cardinality helps describe how certain entities relates with others in the form of

either one-to-one, one-to-many, many-to-one, and many-to-many. Using the Blue Mountains

College database as an example, the occurrences below shows cardinalities:

I. Each room in the College is related to a building- one-to-one cardinality.

II. Blue Mountains Campus has multiple buildings- one-to-many.

III. A student can only be a member of one department- Many-to-one cardinality.

Essentially, a one-to-one cardinality implies a situation in which in one-to-one cardinality,

one table row in the first entity relates only with one row in the second entity. As for a one-

to-many cardinality, a single table row in the first entity relates to several other rows in the
 Database Design Project 5

second entity. Lastly, a many-to-many cardinality refers to a scenario whereby the several

table rows in the first entity relates with several other rows in the second entity. Cardinalities

therefore describe the maximum and minimum number of entities which may be linked to the

second entity.

4. Surrogate, Candidate, and Primary Keys

Surrogate Keys are any column or columns that satisfy the criteria of primary keys rather

than natural or real primary keys. A candidate key refers to a super key with no repeated

attribute. Each table must contain at least one candidate key and the primary key is chosen

from the list of candidate keys. A primary key is a special constraint on a column or in a set

of columns that is used to uniquely identify each row. The value can neither be duplicate nor

appear once in a table and cannot also be a null value.

The Table 1 indicates some of the surrogate, candidate, and primary keys from Blue

Mountains College database.

Database Design Project 6
 Database Design Project 7

5. Conceptual Model Entity-Relationship diagram

The conceptual model-entity relationship diagram above is useful as it represents user

requirements and serves as a focal point for discussing requirements and determines whether

the user needs are correctly understood. The basic component of the Blue Mountains College

database teaching process is the Entity, which represents the ‘real world’ object of concern.

The Attributes in the diagram describes Entities which contain specific data elements for

which the data is stored. As illustrated, Entities are connected via links (these are represented

by lines); these Entities demonstrate the correlation between two or more Entities.
 Database Design Project 8

Part Two: Logical Modelling

1. Description of Data Attributes

Attributes are the features that entities possess in each database. Each Entity attribute is

described by a name that is relevant to what it does or its relevance to the entity. Every

attribute also bears more features such as its type of data, whether the attribute is null or not,

default values if needed, and also format limiters that the attribute can contain. Concerning

the case of Blue Mountains College, the main attributes identified for the database are

illustrated as follows:

Employees:

The Employee Entity contain the following attributes and their associated data types:

I. Employee ID: Contains data type of strung to enable combinations of symbols,

numbers, and letters.

II. First_Name: Contains a data type of string.

III. Last_Name: Also contains data type of string.

IV. Hire Date: Contains an integer data type.

Staff

I. Employee ID: Contains an integer data type.

II. Staff Level: Contains data type char.

Administrator:

I. Employee ID: Contains an integer data type string.

II. Employee Position: Contains an integer data type string.

Lecturer
 Database Design Project 9

I. Employee ID: Contains an integer data type string.

II. Specialty: Contains an integer data type string.

III. Rank- Contains an integer data type string.

IV. Code: Contains an integer data type integer.

Faculty

I. Faculty ID: Contains an integer data type string to accommodate symbols, numbers,

and letter.

II. Faculty Name: Contains an integer data type string.

Department:

I. Department-ID: Contains a suitable data type string.

II. Department-Name: Contains a suitable data type string.

III. Faculty-ID: Contains a suitable data type string.

Course:

I. Course ID: Contains data type - string.

II. Course Title: Contains data type - string.

III. Course Description: Contains data type string.

IV. Department ID: Contains datatype string.

Student:

I. Student ID: Contains string type.

II. Student First_Name: Contains data type string.

III. Student Last_Name: Contains suitable type string.

IV. Student Email: Contains suitable data type string.

V. Employee ID: Contains suitable datatype string.

 Database Design Project 10

VI. Department ID: Contains suitable datatype type string.

Enrollment:

I. Student ID: Contains suitable data type string

II. Class ID: Contains suitable data type string

III. Enrollment Date: Contains suitable data type string

IV. Enrolment Grade: Contains suitable data type string.

Room:

I. Room ID: is assigned data type string.

II. Room Type: is assigned data type string.

III. Building ID: is assigned data type string.

Building:

I. Building Name: assigned data type string.

II. Building ID: assigned data type string.

III. Building Location: assigned data type string.

Class:

I. Class ID: Unique ID for each class is assigned data type string.

II. Class Time: Contains suitable data type string.

III. Room Code: Contains suitable data type string.

IV. Course ID: Contains suitable data type string.

V. Employee ID: Contains suitable data type string.

2. Identification of foreign keys for each entity

Foreign keys refer to attributes for one entity which refers to values in an attribute in a

different entity. Foreign keys are the cornerstone of relationships in relational databases and
 Database Design Project 11

eliminates complexity so that data and fields are not repeated when represented within

database tables. Harrington (2016) submits that a consistent naming convention ought to be

specified and used throughout the database in relation to foreign keys. For example,

Attributes and Entities are generally named using singular nouns. The actual convention

chosen may be subject to the database software utilised. Certain databases will permit several

words for attribute and entity names, such as Emp_ID for department and Dept_ID for

course. The Blue Mountains College database has the following foreign keys as shown in

Table 2.

3. Describe any one-to-one relationships

 Database Design Project 12

Database tables can be related in multiple ways. A one-to-one relationship is one, one to

many and many to many are others. A one-to-one relationship exists when one row in a table

is linked with exactly only one row in another table. This is the least common database

relationship since it does not offer much in terms of benefit to break the fields out of the

“main” table. Also, a one-to-one relationship is not a property of the data, instead it is of the

relationship itself.

A true one to one relationship is one where each table may contain only one row for each

entity. For example,

 At any instance, one room is assigned to one class.

 At any instance, one Lecturer will belong to a one faculty.

 At any instance, one staff member will be allocated to one student to be his or her

advisor.
 Database Design Project 13

4. Logical Model diagram

Conclusion

This study has designed the conceptual model of Blue Mountains College teaching process

including identification of entities, entities supertypes and subtypes, inheritance and

discriminators. The study has also described the relationship between entities and their

cardinalities. Taken together, a conceptual model illustrating the entity-relationship between

the Entities has been developed. Similarly, a logical model showing the attributes and their

types for each entity has been described. These are analysis approaches which can be used to

clearly perceive how the database is structured and how it can work and function in

implementing the gaols of the collage in storage, retrieval and manipulation of relevant data

as pertaining to the teaching processes at Blue Mountains Collage.

 Database Design Project 14

List of References

Al-Masree, H.K., 2015. Extracting Entity Relationship Diagram (ERD) from relational

database schema. International Journal of Database Theory and Application, 8(3),

pp.15-26.

Harrington, J.L., 2016. Relational database design and implementation. Morgan Kaufmann.

Riggs, R., Goldman, D., Remmel, H.M.T., Sandys, S. and Wolfe, J., LOCUS LP, 2019.

Segmentation and stratification of data entities in a database system.