Design a database according to the description below.
Meowmeow Cakehouse is a wellknown layered cake maker in Kuching. It sells various type of layered cakes in the shop. As layered cake is often baked for religious or cultural celebrations, thus they must be classified by both color and pattern. Meowmeow Cakehouse is looking for a database system to ease their daily operation. Beside storing cake information and their classification, the system must be able to store different recipes of different layered cakes accordingly to different bakers. Information such as ingredients, their quantity/measurement, cost per units must be recorded in order to computed the total cost for a layered cake.
Meowmeow Cakehouse usually open from 9am to 10pm to allow walk in customers to purchase their favorite cake instore. They also allow preorder of layered cake if certain cakes are not available at that time. Preorder requires deposit of RM25. However, bear in mind that customer only allow to order cake from the already defined cakes. In addition, they sell their cake online which each cake will be charged flat shipping fee of RM7.90.
Meowmeow Cakehouse offers membership program for instore only. Each member enjoy 10% discount of all the layer cakes. For every layered cake sold, the baker will be commissioned 5% of the cake prices and the cashier will receive 3% of commissions.
Meowmeow Cakehouse requires a database system (includes point of sale, recipe management, employee commission(excluding their payroll)) which is able to print invoices, recipe, monthly and yearly sale report, bakers commission and etc.
The following assumptions applied:
Task:
Your submission should include business rules, an ERD and a data dictionary. The ERD should include entities, attributes, relationships, connectivities and cardinalities.
Method of handin:
A copy of printed work for each group. Each member must upload soft copy through a link provided on eLEAP
5 
4 
3 
2 
1 
0 

Notation 
Diagram uses appropriate crow foot ER notation. The notation is used correctly for all elements of the diagram. 
Diagram uses an appropriate crow foot ER notation. The notation is used correctly for 75% elements of the diagram. 
Diagram uses an appropriate crow foot ER notation. The notation is used correctly for 50% elements of the diagram. 
Diagram uses an appropriate crow foot ER notation. The notation is used correctly for 25% elements of the diagram. 
Diagram does not use an appropriate crow foot ER notation or uses a notation incorrectly for less than 25% elements. 
Diagram does not use crow foot ER notation. 
Entity 
Diagram captures all entity sets necessary for a database that would satisfy the initial problem statement. 
Diagram captures most entity sets necessary for a database that would satisfy the initial problem statement. 
Diagram captures less than 3 of the entity sets necessary for a database that would satisfy the initial problem statement. 
Diagram captures none of the entity sets necessary for a database that would satisfy the initial problem statement. 

Keys 
Diagram captures all attributes, primary keys and foreign necessary for a database that would satisfy the initial problem statement. 
Diagram captures 75% attributes, primary keys and foreign necessary for a database that would satisfy the initial problem statement. 
Diagram captures 50% attributes, primary keys and foreign necessary for a database that would satisfy the initial problem statement. 
Diagram captures 25% attributes, primary keys and foreign necessary for a database that would satisfy the initial problem statement. 
Diagram captures less than 25% attributes, primary keys and foreign necessary for a database that would satisfy the initial problem statement. 
Diagram captures none of the primary and foreign keys necessary for a database that would satisfy the initial problem statement. 
Constraints 
Diagram captures all cardinality and participation constraints necessary for a database that would satisfy the initial problem statement. 
Diagram captures 75%cardinality and participation constraints necessary for a database that would satisfy the initial problem statement. 
Diagram captures 50% of the cardinality and participation constraints necessary for a database that would satisfy the initial problem statement. 
Diagram captures 25% of the cardinality and participation constraints necessary for a database that would satisfy the initial problem statement. 
Diagram captures only cardinality or participation constraints necessary for a database that would satisfy the initial problem statement. 
Diagram captures none of the cardinality and participation constraints necessary for a database that would satisfy the initial problem statement. 
EERM 
N/A 
N/A 
Diagram captures all disjoint/overlapping and completeness constraints, necessary for a database that would satisfy the initial problem statement. 
Diagram captures most disjoint/overlapping and completeness constraints, necessary for a database that would satisfy the 
Diagram captures some disjoint/overlapping and completeness constraints, necessary for a database that would satisfy the 
Diagram captures none disjoint/overlapping and completeness constraints, necessary for a database that would satisfy the 
initial problem statement. 
initial problem statement. 
initial problem statement. 

Relationship 
N/A 
N/A 
All relationship are named 
More than 50% relationship are named 
Less than 50% relationship are named 
No relationship name. 
Business Rules 
N/A 
N/A 
All business rules can be translated into ERD 
More than 50% business rules can be translated into ERD 
Less than 50% business rules can be translated into ERD 
No business rule. 
Criteria (weight) 
5 
3 
1 
Score 
Exemplary 
Satisfactory 
Needs Improvement 
(Weighted) 

Notation (x2) 
Diagram uses an appropriate ER notation. The notation is used correctly for all elements of the diagram. 
Diagram uses an appropriate ER notation. The notation is used correctly for most elements of the diagram. 
Diagram does not use an appropriate ER notation or uses a notation incorrectly for most or all elements. 

Complexity (x1) 
The required number of tables and foreign key relationships will be needed to implement the database. 
As drawn, the required number of tables and for eign key relationship may not be needed, but the required complexity can be achieved with minor changes. 
The required number of tables and foreign key rela tionship will not be needed. It is unclear how the pro ject could satisfy the re quired complexity. 

Professionalism (x1) 
Diagram presents a professional appearance. It could be shared with a “realworld” customer 
Diagram largely presents a professional tone. It could be shared with a “real world” customer with minor 
Diagram is unprofessional. Major revisions would be necessary before sharing the document with a “real 
TMF2034—Database Concept and Design
Criteria (weight) 
5 
3 
1 
Score 
Exemplary 
Satisfactory 
Needs Improvement 
(Weighted) 

Constraints (x1) 
Diagram captures all cardinality and participation constraints necessary for a database that would satisfy the initial problem statement. (Recognizing that if all relationships are legitimately manymany with partial participation, 
Diagram captures most of the cardinality and partici pation constraints neces sary for a database that would satisfy the initial problem statement. 
Diagram captures none or few of the cardinality and participation constraints necessary for a database that would satisfy the initial problem statement. 
Assignment Writing Help
Engineering Assignment Services
Do My Assignment Help
Write My Essay Services