DATA MODELING AND MANAGEMENT
SPORTS CLUB SYSTEM REPORT ANALYSIS
UNIFIED MODELLING DIAGRAM- UML
The unified modeling language is the standardized modeling structure used to develop the complex system. Unified modeling is widely prioritized while developing object-oriented systems as it integrates best designs and represents the simplified models.
Generally, there are two UML diagrams- structure diagram and behavior diagram divided into 13 sub diagrams used by system stakeholders on multiple occasions.
Structure Diagram
It provides the static model specifying the component abstraction, design layers, implementation, and deployment of the system.
· Class Diagram
· Component Diagram
· Deployment Diagram
· Object Diagram
· Package Diagram
· Composite Structure Diagram
Behavior Diagram
It represents the behavioral changes between the objects, actors, and components with time and state in the system. It is further categorized into the following structures.
· Activity Diagram
· State Machine Diagram
· Sequence Diagram
· Communication Diagram
· Interaction Diagram
· Timing Diagram
Use-Case Diagram
UML model best describes the system functionalities in terms of associated use cases and actors who are participating in the system. This model is specially used by the developers during the planning and designing phases as it builds behavioral understanding with the environment.
BREIF USECASE DESCRIPTION
For this project also, we have selected use-case UML to identify the sports club system behavior when the member or staff interact with the system. Here, staff and club members are primary users interacting with the system. Each user must log in to the system before being facilitated by the system features, new users will register themselves first, and the system will authenticate the member information (MID, SID) with stored data. Members can maintain personal information and access the day activities, bookings, and available slots for booking. The system will ensure members that booked slots shouldn’t coincide on the same day/time. Staff members can search them and view the activities, maintain the attendance record, update/review personal information. At the same time, the system server will be responsible process the request and retrieve/update delete data according to a particular command.
Extended Use Case Description
DESIGN ISSUES AND CHALLENGES
We have selected a use case model to describe how our actors and system will interact with each other, how the system will respond when users request for the service, what type of database we will use and how web API and service providers work on request. Our team has decided first to design an activity diagram as it will give exposure to the communication and business process and defines the organization structure. However, it doesn’tprovide room for error, and thus, modifications in the system component are not possible while following the activity diagram. Use-case diagram displays the use-case behavior on certain events when the user interacts with the system. It defines the system scope and is designed by focusing on high-level functional requirements. Plus includes the system actions (authentication/internet service provider, data manipulation) and is less complex than other UML models. However, it doesn’t specify the decision process and user action. For instance, a member may book or not book the activity. If members didn’t book the activity, what will happen next. The booking feature is choice-based. Also, what will happen when the open application, how system authenticates user, these steps are missing from the use-case UML.
ERM
ERM- entity-relationship model is derived from the entity-relationship (ER) and how entities are interacting with each other within the system. It is the key model for the development of database design management and business processes. It specifies the elements/entities involved in the system and their relationship with others. Also, it identifies the data flow and control decisions of the design on the arrival of a specific event. ER model is also used in relational database designing. The entities are defined as the tables with their attributes and foreign/primary to identify relationships between them in the system database schema.
Component and Cardinality
ER models are formulated mainly with- entities, relationships, cardinality, and attributes.
Entities define the object with characteristics whose data is stored and manipulated. Entity types are the definable objects (parent with sub-branches of items associated with it), for instance, members and staff in this project. Entity set targets the particular event/activity performed by the system or actors, such as members making bookings and staff marking members attendance. Each entity hold keys defined as a super, candidate, primary, and foreign keys. In this project, we are using primary and foreign keys, a primary key holds unique data of the entity set, and a foreign key defines the relationship between entities. In the below figure, each entity has its primary key, for instance, MID in member set which is linked with booking set through foreign key MID while booking entity is using BID as the primary key.
Relationship act as connecting components defining the particular action/decision by an entity in the software development. They often form a recursive relationship with the entity over certain decisions where choices are provided.
Attributes holds the object/entity properties, which are divided into key(primary), simple and partial key (foreign) attributes. They can be categorized into simple, composite, and derived. Simple attributes can’t be split into child attributes, for instance, Member email ID, activity name. Composite attributes are single originated from other attributes, and derived attributes are drive from attributes with sub-data forming that attribute. For instance, in Member entity name can be divided into first name and l name, address can be divided into house number, street and city attributes forming the member address.
Cardinality
It defines the type of relationship between entities. Cardinality is divided into one-to-one, one-to-many, and many-to-many.
1. One-to-One: one member can access one activity or can book one slot at a time.
2. One-to-many: members are open to book as many activities at a time. Similarly, one staff member can mark many member’s attendances and view activities.
3. Many-to-many: Many members can book many slots, or many staff members can mark attendance of many classes.
In this project, one/many members can’t book (optional) or book many activities and slots. Many/single members can view many/single activities and available slots. Staff must attend and mark optional/many attendances. Staff can view/can’t view the many/optional activities and booked slots.
DESIGN ISSUES AND CHALLENGES
· Our Entity-relationship model diagram focuses on the database schema design and defines how the user interacts. During this project, we had unclear requirements due to which we need to modify table relationships and entities. Still, it is difficult to integrate with changes in ER model as it creates complexity. Also, the ER model works with clearly defined rows (attributes and columns (entities) only due to the cardinality relationship. We got confused at this point because, in our project, some entity has limited access to the linked entity. For instance, only staff can record the attendance, while members have no access to the module. ERM is only followed for the relational database. If the system uses the cloud for storage, ER model is not applicable for database management. Also, ERM is not understandable by the business person and common user.
SQL QUERIES
Following are the queries used when the members request to view current booking and current activities.
1. Display activities by member 01 and current activities available in sports club — SELECT Activity-name FROM `Activity` WHERE MID ₌ M01; OR SELECT Activity-name FROM `Activity’ WHERE DAY BETWEEN ‘2021–9–6’ and ‘2021–9–13’
2. Display all current booked activities with slots -SELECT Booking-history, slots FROM `Booking’ WHERE DAY BETWEEN ‘2021–9–6’ and ‘2021–9–13’