A Complete Database Design For Shopping Mall

SHOPPING ABV-IIITM
DBMS
MALL PROJECT
REPORT
DATABASE BCS-2020
A Complete Database Design By
For Shopping Mall Ramesh Reddy

Bhanu Bainsala
Akshith Gandla
Harshit Agarwal
J J Loknath
A Complete Database Design
Laukik Shah
For Shopping Mall
ABV-IIITM, GWALIOR |1
Shopping Mall Database
A DBMS Project
Submitted By
Baddam Ramesh Reddy, 2020BCS-019
Bhanu Jatin Singh Bainsala, 2020BCS-020
Gandla Askhith, 2020BCS-030
Harshit Agarwal, 2020BCS-037
J J Loknath, 2020BCS-041
Laukik Shah, 2020BCS-050
(Bachelors of Technology in Computer Science)
Under The Guidance Of

Dr Debanjan Sadhya
Through
Atal Bihari Vajpayee
Indian Institute of Information Technology
And Management (ABV-IIITM), Gwalior
ABSTRACT
With Western lifestyle being portraited as modern way of leaving, popularity of

shopping malls is ever growing in today's world. They have become an integrated part
of the life of many people. Shopping mall has not remained just a place for shopping
essential items, but they are becoming more diversified and have become the spot
the spend a day. Considering the pre-pandemic era and the world that will emerge
after, Shopping tourism will be on the rise. However, proper management is required
to be in place for a mall to be successful. Through our project 'Shopping Mall
Database', we have designed and implemented an Entity Relationship Model of data
for the shopping mall database. We proceeded through the Entity Relationship
Diagram and Normalisation. We have attempted to solve the problems of data
duplicity and anomalies effectively.
INDEX
Abstract ............................................................................................................................... 2
Index .................................................................................................................................... 3
1 Introduction .................................................................................................................. 4
The Idea ................................................................................................................ 4
Why we chose this topic? .................................................................................... 4
Project Introduction .............................................................................................. 5
2 METHODOLOGY ........................................................................................................... 6
3 Brainstorming................................................................................................................ 8
The Sections .......................................................................................................... 8
4 ER Diagram................................................................................................................. 17
5 Normalisation ............................................................................................................. 19
6 Implementation ......................................................................................................... 34
Dummy Data ...................................................................................................... 34
Relational Algebra ............................................................................................. 39
SQL ....................................................................................................................... 44
7 Our Learnings ............................................................................................................. 49
8 REFERENCES................................................................................................................ 50
1 INTRODUCTION
The Idea
Shopping malls are one of the favourite shopping places for most of us. They provide
many items or sometimes- all from clothing, footwear to electronics and gaming in
one place—no wonder why some like to spend a whole day there. The concept of
'Shopping mall' has no bounds. They can be from the small number of shops that can
be counted on fingers to so large that it takes a day to visit all the shops. Such large
shopping malls also provide some shared facilities, such as a food court, leisure area,
lawn to sit on or sitting areas for the consumers to spend time and eat something
during shopping so that they do not leave the mall if they are hungry. Obviously, they
earn a high return on these investments.
Managing such large malls is a difficult task. You must have proper systems in place
designed and explicitly altered for your case. These systems involve security, parking
management, IT systems such as CCTV surveillance and common area WIFI and many
more. These include one common task- Database Management. To have a proper
record of all the things and their management, it is essential to have a good database
in place.
Through this Database Management Project, we have made an attempt to design

and implement a complete database system for the shopping mall.
Why we chose this topic?
Thinking of the designing of databases, there are many topics that can be opted for.
However, the shopping mall database is one of the most complex databases. It
involves many entities whose role is repeated often. For example, an organisation,
Reliance Industries, owns two brands Jio, a telecommunication company and Fresh
Mart, a retail mart chain, both of which have a shop in the mall. Mall also takes IT
services from a subsidiary of Reliance. In this case, there is a possibility of data
redundancy of data of Reliance Industries. It is a challenging task to design a perfect
data model for all needs of the mall. We wanted to do something challenging, out of
the way, which would require a deeper understanding of the concepts and total
dedication. This topic is also fascinating compared to the other 'traditional' database
models that are typically chosen.
Another perspective is the expandability of the project. A shopping mall can range
from just a small collection of shops to an integrated lifestyle mall which includes but
is not limited to the integrated food court, common areas and events in the mall. We
can design features as 'add on' to the work we have already done, such as a library
to spend some time and expand the project as much as desired.
By choosing the topic, we knew that we would acquire more knowledge about
designing databases and their implementation than what we would have acquired
from some other database systems such as a library. We would also be able to
understand the work of the data model designers and appreciate it.
Project Introduction
In the project, we have designed the complete database for the shopping mall,
which may be implemented in real life. The path starts from the virtual visits to the mall
and brainstorming to the demonstration of our model through SQL and Relational
Algebra queries. It also includes normalising the relations involved and mapping entity
and relationship sets into ER diagram. This report explains all the steps and their
outcome in detail.
2 METHODOLOGY
After having an overview of the topic, it was time to dive into it and begin with the
actual work. We began with surfing the web for a better understanding of the topic.
This was a very crucial part of the project. The first problem we faced was that the
malls were closed due to the pandemic, and we could not have an actual visit. To
overcome this, we browsed through the websites of various shopping malls and had
a walk-through of the virtual malls of the internet, observing each little detail and
noting it down. It required us to view the processes and management part of the mall
from the manager's perspective and appreciate their work. We also recalled our
previous visits to the mall.
As we shaped our basic idea and understanding of the mall and its management, we
began to list down the various departments or the sections and their responsibilities
before going to the data model designing. We identified all the entities related to the
mall and how they were related. We made business decisions such as the attributes
to include. The best evidence of this would be the inclusion of records of visitors and
their groups. This includes but not limited to families and friends. Maintaining a record
of groups of visitors was not a necessary part of the management and operations of
the mall, but it would provide valuable business data and analytics which could be
used for business expansion and deciding marketing tactics.
Coming to the data model was the most challenging part of the project. It tested our
understanding of various concepts of the theory. We were required to structure the
data correctly so that there will not be any redundancy and null values. Avoiding
redundancy and null values were the main guidelines for structuring the data model.
For example, a person or an organisation can be related to the mall in different ways.
In such cases, it would have happened that the person has an entry in both the
relations causing data redundancy. For that, we designed the system of recognised
persons and organisations. It would act in a way similar to Aadhaar Card acts for the
Indian citizens. It is used to identify the same person in various places by various
departments and systems. We designed the data model in such a way that its real-
life commercial implementation would be possible without much changes.
Once the data model was done, the task was to identify the entity and relationship
sets and map them into the ER diagram. It also included the identification of
cardinality constraints and the nature of the entity sets. We used the online tool,
draw.io, for designing the ER diagram collaboratively. As our data model is vast, we
could not include all the entity and relationship sets in the ER diagram. We have used
the standard notations taught in the course for the ER diagrams to avoid confusions.
Coming to normalisation, we identified the primary keys and all the functional
dependencies for every relation. Then we analysed and decomposed the table step
by step to the Boyce–Codd Normal Form (BCNF).
The next task was the actual implementational and demonstration of our data model.
For this, we designed some Relational Algebra and SQL queries, showcasing the
actual usage and capability of our data model. The required dummy data was
generated in MS Excel, and some were also obtained through online resources. Then
it was then uploaded to the RelaX - relational algebra calculator, the platform we
used to run the queries. Results can be found in the implementation section.
3 BRAINSTORMING
This section of the report includes the relations that we come up with after the
brainstorming, grouped into sections, for proper organisation of the database. Each
section explains the logic behind the designing of relations and rules for the relations
that it includes.
Recognised persons and Recognised organisations are a generalisation of all the

persons and organisations that are related to the mall. Employee and Representative
are specialisations of recognised persons whereas owner organisation, operator
organisation is a specialisation of Recognised organisation. This is done to reduce the
data redundancy and work in the same way as Aadhaar works for Indian citizens and
Udyog Aadhaar works for Indian businesses. None of the tables outside the finance
department except vehicles will maintain historical records.
The Sections
3.1.1 Recognised Persons
Notes, Logic and Rules:
1. Every RP must have specific information

2. A person can be related as: Mall Employee/ Contracted Employee
Property Owner, Owner Representative
Operator, Operator Representative
Contractor Organisation Representative
● Person Details
RP Details (RPID, Name, Gender, Address (Line1, Line 2, City, State, PIN), Date of
Birth, domicile state, Phone Number, Email id)
● Person Docs
RP Docs (RPID, Aadhaar, Pan)
3.1.2 Recognised Organisation:
1. As an organisation can have multiple representatives for different purposes, we

would not include Representative here
2. Every RO must have specific information

3. An organisation can be related as: Property Owner
Property Operator
Brand Owner
Service Provider
● Organisation Details
RO Details (ROID, Registered Name, RO Type, Registration Address (Line1, Line 2,
City, State, PIN), Date of Registration, Phone Number, Email id)
● Organisation Docs
RO Docs (ROID, RegistrationID, GSTN)
3.1.3 Mall Employees:
1. Manager with no further managers will have their own EmployeeID as

Supervisor Eid - to avoid null values
2. There will not be any separate departments distinctly representing the
employees as such
3. Category- Cleaner, Salesman
● Employee Details
Employee Details (EmployeeID, Category, SupervisorEmployeeID, Type (Direct/
Contracted), DoJ, Salary, RPID)
● Employee Docs
Employee Docs (EmployeeID, BAccountID, Police Verification Certificate, UAN)
3.1.4 Owner, Operator and Representative
1. We made separate Owner, Operator and Representative tables instead of

directly assigning RPID or ROID because:
a. To replicate actual real-life scenarios instead of simplifying them
b. To avoid making two tables to store the same information like owner or
operator of a particular property by basis such as single owner or
organisation
c. To reduce the complexity of database structure
d. To completely avoid redundancy
2. By making a separate table, we can add more attributes for a peculiar entity
set, say operator, if required. We would not be able to do so, if we directly
A B V - I I I T M , G W A L I O R | 10
assigned ROID or RPID in the tables Property Owned by and Property

Operated By
● Owner
Owner Details (OwnerID, ROID/RPID)
● Operator
Operator Details (OperatorID, ROID/RPID)
● Representative
Representative Details (RepresentativeID, RPID)
3.1.5 Property, It's ownership and operator:
1. Each property owner and the operator must have a representative. They can
be owner/ operator himself
2. Property operation can only be done by a single operator or organisation. For
partners, they need to form organisation
3. Making total stake percent 100 is not a problem of redundancy or null values.
It is the problem of data validity which is to be solved by other systems.
4. Adding OwnershipType (Single Owner, Partner, Organisation) attribute in
property details increases data redundancy.
5. All Ownership Types (Single Owner/Partner/Organisation) share common
attribute OwnerID. Similarly, all Operator types (Owner/Leased) share
common attribute OperatorID. This is done to avoid splitting a single table into
two.
6. Consider: one owner can own multiple properties, may have the same or
different Representative. Similarly, one operator can operate multiple
properties, may have the same or different Representative.
7. For the Property Owned by table, the primary key would be K (PropertyID,
OwnerID). We would consider DateOfStakeTrxn as the date of the last stake
transaction i.e., buy or sell.
8. Properties operated by the owner also can have two different
representatives- one from the role of owner and one from the role of
operator.
9. One property can have multiple owners, but can only be operated by a
single operator.
10. For the property operated by the owner, we can set its rent and tenure to 0.
● Property Details
Property Details (PropertyID, Property Number, Floor, Area, Description)
● Ownership, and Representative (Authorised person from owner)

Property Owned by (PropertyID, OwnerID, DateOfStakeTrxn, Stake %,

RepresentativeID)
● Operation and Representative (Authorised person from operator)

Property Operated by (PropertyID, OperatorID, OperatorType (Owner/Leased),
DateFrom, RepresentativeID, Rent, tenure)
3.1.6 Visitors and Parking:
1. Every visitor will have VisitorGrpID, which would help us to maintain and
identify the groups of visitors.
2. Visitor is not a recognised person.
3. Group can be of a single person.
4. There is no necessity of forming groups, but it provides much valuable
analytical information.
● Parking Slot
Parking Slot (ParkingID, SectionID, Type (Two/Four-wheeler))
● Visitor Vehicle
Vehicle (VehicleNumber, ParkingID, InTime, OutTime, VisitorID, INTrxnID)
● RP Vehicle
RP Vehicle (VehicleNumber, ParkingID, InTime, OutTime, RPID)
● Visitor
Visitor (VisitorID, VisitorGrpID, Name, Age, BodyTemp, PhoneNumber, InTime,
OutTime)
3.1.7 Assets:
1. Each asset has a different AssetID.

2. Each asset belongs to a group and has AssetGrpID.
3. Assets of the same type can have different GrpID, for e.g., if purchased at
different times. Assets of different types will have different GrpID.
● Assets
Assets (AssetID, AssetGrpID, Location)
● Asset Group
Asset Group (AssetGrpID, InvoiceNo, AssetType, Description)
3.1.8 Shop Details:
1. Every shop will have a unique ShopID (Primary Key), We divide shops into their
respective categories like electronics, groceries etc.
2. Shop Owner/ operator will have to maintain employee details in mall's system
3. Same brand can have products in different categories. Different brands can
be owned by the same company.
4. Shop Commodity maintains the list of product categories that a particular
shop sells with BrandID and PriceRange.
● Shop Commodity
Shop Commodity (ShopID, Category, SubCategory, BrandID, PriceRange)
● Shop Details
Shop Details (ShopID, PropertyID, Revenue, MonthlyMaintenance,
RevenueSharingPercentage, DWaterMeterID, NWaterMeterID, ElectricityMeterID)
● Brand Info
Brand Details (BrandID, BrandName, ROIDofBrandOwner)
● Shop Employees
Shop Employees (ShopID, ShopEmployeeID)
3.1.9 Shop Employees:
1. Manager with no further managers will have their own Eid as Supervisor Eid -
to avoid null values
2. No separate departments
3. Category- Cleaner, Sales man etc
● Shop Employee Details

Shop Employee Details (ShopEmployeeID, Category, SupervisorEmployeeID, Type
(Direct/Contracted), DoJ, RPID)
3.1.10 Meter Details:
1. Records electricity and water usages

● Electricity Meter Details

Electricity Meter Details (ElectricityMeterID, Last Reading, This Reading, Consumer
Number)
● Drinking Water Meter

Drinking Water Meter (DWaterMeterID, Last Reading, This Reading)
● Normal Water Meter

Normal Water Meter (NWaterMeterID, Last Reading, This Reading)
3.1.11 Mall Anonymous - Lists
Mall electricity meters
Mall Drinking Water Meter
Mall Normal Water Meter
3.1.12 Finance
1. All transactions will be divided in three categories- Payments Received,

Payouts and Salary Payment- Spayout
2. Tables, like visitor parking, that maintain records after the use will have TrxnID
associated, whereas tables that do not hold records will not have any
attribute for payments
3. Payment Receipts:
o Each received payment will be provided with payment receipt
o Payments receipts will have INTrxnID associated with them
o Payment From - OwnerID/ OperatorID/ BrandID (OwnerID only when shop is
not operational)
o Payment for: Revenue Share, Temporary Shop, Water Usage, Advertisement
4. Payouts:
o Payout should only be made against invoice. Contractors should also issue
them.
o Payouts will have OUTTrxnID associated with them.
o Payout To- ProviderID
o Payout for: Goods, Services
5. SPayouts:
o SPayout will be done to mall employees
6. TrxnIDs
o INTrxnID and OUTTrxnID will have technical and transactional details where as
payment receipts and invoices will have other details associated with them
o Reference Number- For cash it will be generated by system, for bank transfer,
it would be TransferID, for cheque- ChequeID
o Modes of payouts: bank transfer- IMPS, NEFT, RTGS, cheque
o Mode of payments: bank transfer- IMPS, NEFT, RTGS, cheque, cash (only for
parking charges)
7. For the tables Cheque Details, Transfer Details and Bank Accounts, IDs are
created instead of using Cheque Number, UTN and Account Number for
security purposes.
● Payment Receipts
Payment Receipt (ReceiptID, PaymentFrom, Payment For, INTrxnID, Description)
● Payouts
Payouts (InvoiceID, PayoutFor, OUTTrxnID, Description)
● Salary Payout
SPayout (SPayoutID, EmployeeID, ForMonth, OUTTrxnDetails)
● Inward Transaction Details

INTrxnDetails (INTrxnID, Amount, ModeOfPayment, DateTime, ReferenceNumber)
● Outward Transaction Details

OUTTrxnDetails (OUTTrxnID, Amount, ModeOfPayout, DateTime,
ReferenceNumber)
● Cheque Details
Cheque (ChequeID, ChequeNumber, BAccountID)
● Transfer Details
Bank Transfer (TransferID, Mode, FromBAccountID, ToBAccountID, UTN)
● Bank Accounts
Bank Account (BAccountID, BankName, AccountNumber, IFSC)
3.1.13 Advertising Management
1. In table "Advertisement Board":

o "Type" attribute here tells us the way in which it was advertised as in Digital
Signage, Hoardings, Standees, Banners, etc.
2. In table "Advertisement"
o "Fees" represents the amount paid to the shopping mall authorities to put up
the advertisement. It represents the current fees which may be different from
what the advertiser has actually paid. We can find record of what advertiser
has actually paid in Payment Receipts
o "Contract Period" is the time period during which the respective organisation
can put up any desired advertisement if they follow the contract rules and
regulation
3. Only Operators or brands can advertise on the advertisement boards of mall-
Indicated by advertiser type
● Advertisement Boards
Board (BoardID, Type, Location, Size)
● Advertiser
Advertiser (AdvID, Type, BrandID/OperatorID)
● Advertisement
Advertisement (AdvertisementID, AdvertiserID, BoardID, Contract Period
(StartDate, EndDate), Fees, Description)
3.1.14 Services and Contracts
1. The Service Provider/Contractor is an organisation.

2. One service provider can be contracted for multiple services
3. ServiceFor may include elevator and escalator maintenance, cleaning, fire
safety, greenery management etc
4. For each service, the contractor must provide an invoice for payout. Its details
will be in finance department)
5. Description of might include any certificates or permissions that service
providers should have
6. Goods will be added in assets
● Services
Service (ServiceID, ServiceFor, ProviderID, Description, Contract Period (StartDate,
EndDate))
● Service Providers/ Seller- For Goods

Provider (ProviderID, ROID, RepresentativeID, Description)
3.1.15 Infrastructure and Other
1. For Temporary shops, there are no owner, only operator

2. TempShop will have one-time fees and no revenue sharing and maintenance
3. TempShop operator will be issued payment receipt against payment
● Promotional Temporary shops

TempShop (TempShopID, ShopFor, OperatorID, RepresentativeID, Description,
Period (StartDate, EndDate))
● Trees and Plants

Trees (TreeName, Numbers, Indoor/Outdoor)
4 ER DIAGRAM
The ER diagram is available at: https://ibb.co/S5qS9W8 in high resolution for better

viewing. Visit the link or scan the QR code to view fully.
5 NORMALISATION
Normalisation is the most crucial part in data bae design. It helps remove
redundancies and anomalies in the database that may have caused problems if kept
unresolved. The process of normalisation to the BCNF form includes various steps such
as listing all the functional dependencies and their analysis. Following is the analysis of
all the relations with functional dependencies and their step-by-step decomposition
to the Boyce–Codd normal form a.k.a. BCNF.
Normalisation
● Person Details
RP Details (RPID, Name, Gender, Address (Line1, Line 2, City, State, PIN), Date of
Birth, domicile state, Phone Number, Email id)
▪ Functional Dependencies:
RPID → Name, Gender, Line1, Line 2, City, State, PIN, Date of Birth, domicile
state, Phone Number, Email id
PIN → City, State
City → State
▪ Analysis and Decomposition:

All the attributes of table are atomic, as well as there is no partial dependency.
Hence the table is in 2NF. However, there exists transitive dependency involving
non-prime attributes. The trouble-causing dependencies are
PIN → City, State
City → State
▪ To convert the table in 3NF, we would decompose tables as below:

RP Details1 (RPID, Name, Gender, Address (Line1, Line 2, PIN), Date of Birth,
domicile state, Phone Number, Email id)
City (PIN, City)
State (City, State)
RPID → Name, Gender, Line1, Line 2, City, State, PIN, Date of Birth, domicile
state, Phone Number, Email id
PIN → City, State
City → State
▪ Now, all the transitive dependencies are resolved. Further, all

the dependencies have prime attributes on their LHS. Hence the tables are
now converted to BCNF.
● Person Docs
RP Docs (RPID, Aadhaar, Pan)
RPID → Aadhaar, Pan
▪ Analysis:
RP Docs entity set is dependent on RPDetails for its existence and connected
as well via linking attribute RPID. By reviewing FDs it is clear that the table is in
BCNF form so no further normalisation required.
5.1.2 Recognised Organisation:
● Organisation Details
RO Details (ROID, Registered Name, RO Type, Registration Address (Line1, Line 2,
City, State, PIN), Date of Registration, Phone Number, Email id)
• Functional Dependencies:
ROID → Registered Name, RO Type, Registration Address (Line1, Line 2, City,
State, PIN), Date of Registration, Phone Number, Email id
PIN → City, State
City → State
▪ Analysis and Decomposition:

Hence the table is in 2NF. However, there exists transitive dependency involving
non-prime attributes. The trouble-causing dependencies are
PIN → City, State
City → State
▪ To convert the table in 3NF, we would decompose tables as below:

RO Details1 (ROID, Registered Name, RO Type, Registration Address (Line1,
Line 2, PIN), Date of Registration, Phone Number, Email id)
City (ZIP, City)
State (City, State)
• Functional Dependencies:
RPID → ROID, Registered Name, RO Type, Registration Address (Line1, Line
2, PIN), Date of Registration, Phone Number, Email id
PIN → City, State
City → State
▪ Now, all the transitive dependencies are resolved. Further, all

now converted to BCNF.
● Organisation Docs
RO Docs (ROID, RegistrationID, GSTN)
ROID → RegistrationID, GSTN
▪ Analysis:
RO Docs entity set is dependent on RODetails for its existence and connected
as well via linking attribute RPID. By reviewing FDs, it is clear that the relation is
in BCNF form so no further normalisation required.
5.1.3 Mall Employees:
● Employee Details
Employee Details (EmployeeID, Category, SupervisorEmployeeID, Type (Direct/
Contracted), DoJ, Salary, RPID)
EmployeeID → Category, SupervisorEmployeeID, Type (Direct/
Contracted), DoJ, Salary, RPID
▪ Analysis:
Employee Details entity set is related with entity sets Employee
Docs, ShopEmployees, ShopEmployee Details, SPayout via linking
attribute EmployeeID and by checking FDs we can determine
that attribute is atomic, no partial and trivial dependency is there. LHS of FDs
are prime attributes so it is already in BCNF form so no further normalisation
required.
● Employee Docs
Employee Docs (EmployeeID, BAccountID, Police Verification Certificate, UAN)
EmployeeID →BAccountID, Police Verification Certificate, UAN
▪ Analysis:
Employee Docs entity set is dependent on Employee Details for its existence
and as well as connected via linking attribute EmployeeID. Now the table is in
BCNF as LHS of all FDs are key.
5.1.4 Owner, Operator and Representative
● Owner
Owner Details (OwnerID, ROID/RPID)
OwnerID →ROID/RPID
▪ Analysis:
Owner Details entity sets is related with entity sets Property Owned By via linking
attribute OwnerID. There is no partial dependency, trivial dependency and LHS
of all the FDs are key so the table is in BCNF.
● Operator
Operator Details (OperatorID, ROID/RPID)
▪ Functional Dependencies
OperatorID →ROID
▪ Analysis:
Operator Details entity sets is related with entity sets Property Owned
By, Property Operated By, Promotional Temporary shops, Advertiser via linking
attribute OperatorID. By reviewing FDs, we can say that all
attributes are atomic, no Partial dependency, no trivial dependency so table
is already in 3NF. LHS of all the FDs are key hence it is in BCNF.
● Representative
Representative Details (RepresentativeID, RPID)
▪ Functional Dependencies
RepresentativeID → RPID
▪ Analysis:
Representative Details entity sets is related with entity sets Property Owned By,
Property Operated By, Promotional Temporary shops, Advertiser, Provider via
linking attribute RepresentativeID. By reviewing FDs, we can say that all
attributes are atomic, no Partial dependency, no trivial dependency so table
is already in 3NF. LHS of all the FDs are key hence it is in BCNF.
5.1.5 Property, It's ownership and operator:
● Property Details
Property Details (PropertyID, Property Number, Floor, Area, Description)
PropertyID →Property Number, Floor, Area, Description
▪ Analysis:
Property Details entity sets is related with entity sets Property Owned By,
Property Operated By, Shop Details via linking attribute PropertyID. By
reviewing FDs, we can say that all attributes are atomic, no Partial
dependency, no trivial dependency so table is already in 3NF. LHS of all the FDs
are key hence it is in BCNF.
● Ownership, and Representative (Authorised person from owner)

Property Owned by (PropertyID, OwnerID, DateOfStakeTrxn, Stake %,
RepresentativeID)
PropertyID, OwnerID →DateOfStakeTrxn, Stake %, RepresentativeID
▪ Analysis:
Property Owned by entity sets is related with entity sets
Property Details, Owner Details, Property Operated By, Operator
Details, Representative Details via linking attribute PropertyID, OwnerID. By
reviewing FDs, we can say that all attributes are atomic, no Partial
dependency, no trivial dependency so table is already in 3NF. LHS of all the FDs
are key hence it is in BCNF.
● Operation and Representative (Authorised person from operator)

Property Operated by (PropertyID, OperatorID, OperatorType (Owner/Leased),
DateFrom, RepresentativeID, Rent, tenure)
PropertyID →OperatorID, OperatorType, DateForm, RepresentativeID, Rent,
tenure
▪ Analysis:
Property Operated By entity sets are related with entity sets Property Owned
By, Property Details, Operator Details, Representative Details via linking
attribute PropertyID. By reviewing FDs, we can say that all attributes are
atomic, no Partial dependency, no trivial dependency so table is already in
3NF. LHS of all the FDs are key hence it is in BCNF.
5.1.6 Visitors and Parking:
● Parking Slot
Parking Slot (ParkingID, SectionID, Type (Two/Four-wheeler))
▪ Functional dependencies:
ParkingID → section, type
▪ Analysis:
All the attributes of the table are atomic, and the only
functional dependency exists is of the primary key. Additionally, primary key is
also atomic. Also, there is no transitive dependency involving non-
prime attributes so it's in 3NF. And, LHS is candidate key Hence the table is in
BCNF.
● Visitor Vehicle
Vehicle (VehicleNumber, ParkingID, InTime, OutTime, VisitorID, INTrxnID)
VehicleNumber, InTime → Intime, ParkingID, OutTIme, VisitorID, INTrxnID.
▪ Analysis:
Hence the table is in 2NF. And, there does not exists any transitive dependency
involving non-prime attributes, so the it is in 3NF. Further, all
now converted to BCNF
● RP Vehicle
RP Vehicle (VehicleNumber, ParkingID, InTime, OutTime, RPID)
VehicleNumber, InTime → Intime, ParkingID, OutTime, RPID.
▪ Analysis:
BCNF. Here RP vehicle entity set is only for the Representative persons who
working in mall. And here vehicle Number, InTime is the candidate key
which uniquely identify all the attributes.
● Visitor
Visitor (VisitorID, VisitorGrpID, Name, Age, BodyTemp, PhoneNumber, InTime,
OutTime)
VisitorID → VisitorGrpID, Age, BodyTemp, PhoneNumber, InTime, OutTime
▪ Analysis:
also atomic and here only VisitorID is the primary key. Also, there is
no transitive dependency involving non-prime attributes so it's in 3NF. And, LHS
is candidate key Hence the table is in BCNF.
5.1.7 Assets:
● Assets
Assets (AssetID, AssetGrpID, Location)
AssetID → AssetGroupID, Location
▪ Analysis:
Hence the table is in 2NF. It is already in 3NF as there is no transitive depending
involving non- prime attributes. Therefore, the table BCNF.
● Asset Group
Asset Group (AssetGrpID, InvoiceNo, AssetType, Description)
AssetGrpID → InvoiceNo, AssetType, Description
▪ Analysis:
BCNF.
5.1.8 Shop Details:
● Shop Commodity
Shop Commodity (ShopID, Category, Subcategory, BrandID, PriceRange)
ShopID, BrandID, Category, Subcategory → PriceRange
▪ Analysis:
This entity set is related to entity set Shop Details, via linking attribute 'ShopID'.
Further, As the entity is dependent on entity set 'Shop Details' for existence, it is
weak entity set. And all the attributes are atomic and there is no partial
dependency so it is 2NF and LHS attributes is the candidate key involving prime
attributes and there is no transitive dependency in the non-prime attributes so
it is 3NF and BCNF.
● Shop Details
Shop Details (ShopID, PropertyID, Revenue, MonthlyMaintenance,
RevenueSharingPercentage, DWaterMeterID, NWaterMeterID, ElectricityMeterID)
ShopID → PropertyID, Revenue, MonthlyMaintenance, RevenueSharingPerce
ntage, DWaterMeterID, NWaterMeterID, ElectricityMeterID
▪ Analysis:
The shop details entity set has strong entity set which will determine shop
commodity entity set which is weak entity set. Without ShopID there is no shop
commodity entity set. Here ShopID is the candidate key. All the attributes of the
table are atomic, and the only functional dependency exists is of the primary
key. Additionally, primary key is also atomic and here only VisitorID is the
primary key. Also, there is no transitive dependency involving non-
BCNF.
● Brand Info
Brand Details (BrandID, BrandName, ROIDofBrandOwner)
BrandID → BrandName, ROIDofBrandOwner
▪ Analysis:
The entity set Brand details will all the brands which are going to sell their items
through the mall. Here BrandID is the candidate key which will determine all
the attributes. All the attributes of the table are atomic, and the only
no transitive dependency involving non-prime attributes so it's in 3NF. And, LHS
● Shop Employees
Shop Employees (ShopID, ShopEmployeeID)
ShopEmployeeID → ShopID
▪ Analysis and decomposition:

Shop Employees entity set is a dependent on shop details because if there is
no ShopID then there is no ShopEmployeeID so it is weak entity set and it is
connected through the ShopDetails entity set via ShopID which is foreign key
here. And all the attributes are atomic and there is no partial dependency so
it is 2NF and LHS attributes is the candidate key involving prime attributes and
there is no transitive dependency in the non-prime attributes so it is 3NF and
BCNF.
5.1.9 Shop Employees:
● Shop Employee Details

Shop Employee Details (ShopEmployeeID, Category, SupervisorEmployeeID, Type
(Direct/Contracted), DoJ, RPID)
ShopEmployeeID → Category, SupervisorEmployeeID, Type
(Direct/Contracted), DoJ, RPID

Shop Employees Details entity set is also a dependent on shop details because
if there is no ShopID then there is no ShopEmployeeID so it is weak entity set and
it is also connected through the ShopDetails entity set via ShopID which is
foreign key here. All the attributes of the table are atomic, and the only
no transitive dependency involving non-prime attributes so it's in 3NF. And LHS
5.1.10 Meter Details:
● Electricity Meter Details

Electricity Meter Details (ElectricityMeterID, Last Reading, This Reading, Consumer
Number)
ElectricityMeterID → Last Reading, This Reading, Consumer Number

Additionally, primary key is also atomic and here only VisitorID is the primary
key. Also, there is no transitive dependency involving non-prime attributes
so it's in 3NF. And, LHS is candidate key Hence the table is in BCNF.
● Drinking Water Meter

Drinking Water Meter (DWaterMeterID, Last Reading, This Reading)
DWaterMeterID → Last Reading, This Reading

Additionally, primary key is also atomic and here only VisitorID is the primary
key. And, there is no transitive dependency involving non-prime attributes
so it's in 3NF. And, LHS is candidate key Hence the table is in BCNF.
● Normal Water Meter

Normal Water Meter (NWaterMeterID, Last Reading, This Reading)
NWaterMeterID → Last Reading, This Reading

involving non-prime attributes, so the it is in 3NF. Further, all
now converted to BCNF
5.1.11 Mall Anonymous - Lists
Mall electricity meters
Mall Drinking Water Meter
Mall Normal Water Meter
5.1.12 Finance
● Payment Receipts
Payment Receipt (ReceiptID, PaymentFrom, Payment For, INTrxnID, Description)
ReceiptID → PaymentFrom, PaymentFor, INTrxnID, Description
▪ Analysis:
involving non-prime attributes, so the it is in 3NF. There are no trouble-
causing dependencies in this entity set. Further, all the dependencies have
prime attributes on their LHS. Hence the tables are now converted to BCNF
● Payouts
Payouts (InvoiceID, PayoutFor, OUTTrxnID, Description)
InvoiceID → PayoutFor, OUTTrxn, Description
▪ Analysis:
prime attributes on their LHS. Hence the tables are now converted to BCNF.
● Salary Payout
SPayout (SPayoutID, EmployeeID, ForMonth, OUTTrxnDetails)
SPayoutID → EmployeeID, ForMonth, OUTTrxnDetails
▪ Analysis:
SPayout entity set will list Finance which were using in the mall. SPayoutID is
unique so it is the candidate key in the entity set. By looking into the functional
dependencies, the entity set is in BCNF so it doesn't require additional
normalisation.
● Inward Transaction Details

INTrxnDetails (INTrxnID, Amount, ModeOfPayment, DateTime, ReferenceNumber)
INTrxnID → Amount, ModeOfPayment, DateTime, ReferenceNumber
▪ Analysis:

● Outward Transaction Details

OUTTrxnDetails (OUTTrxnID, Amount, ModeOfPayout, DateTime,
ReferenceNumber)
OUTTrxnID → Amount, ModeOfPayout, DateTime, ReferenceNumber
▪ Analysis:
OUTTrxnDetails entity set will list Finance which were using in the
mall. OUTTrxnID is unique so it is the candidate key in the entity set. By looking
into the functional dependencies, the entity set is in BCNF so it doesn't require
additional normalisation.
● Cheque Details
Cheque (ChequeID, ChequeNumber, BAccountID)
ChequeID → ChequeNumber, BAccountID
▪ Analysis:
prime attributes on their LHS. Hence the tables are now converted to BCNF
● Transfer Details
Bank Transfer (TransferID, Mode, FromBAccountID, ToBAccountID, UTN)
TransferID → Mode, FromBAccountID, ToBAccountID, UTN
▪ Analysis:
Bank Transfer entity set will list Drinking Water details which were using in the
mall. TransferID is unique so it is the candidate key in the entity set. By looking
● Bank Accounts
Bank Account (BAccountID, BankName, AccountNumber, IFSC)
BAccountID → AccountNumber, BankName, AccountNumber, IFSC
IFSC→ Bank Name
▪ Analysis:
Bank Accounts entity set lists all the bank accounts which are being used in the
mall. BAccountID is unique so it is the candidate key in the entity set. By looking
into the functional dependencies, we can see that there is transitive functional
dependency
IFSC→ Bank Name
▪ Hence, we decompose table as follows

Bank Account (BAccountID, AccountNumber, IFSC)
Bank Name (IFSC, Bank Name)
BAccountID → AccountNumber, BankName, AccountNumber, IFSC
IFSC→ Bank Name
▪ Analysis:
Now there is no FD involving non-prime attribute, as well as there is no functional
dependency with non-prime attribute on LHS. Hence the tables are in BCNF.
5.1.13 Advertising Management
● Advertisement Boards
Board (BoardID, Type, Location, Size)
BoardID → Type, Location, Size
▪ Analysis:
BoardID entity set will list Drinking Water details which were using in the
mall. BoardID is unique so it is the candidate key in the entity set. By looking into
the functional dependencies, the entity set is in BCNF so it doesn't require
● Advertiser
Advertiser (AdvID, Type, BrandID/OperatorID)
AdvID → Type, BrandID/OperatorID
▪ Analysis:
Advertiser entity set is dependent on Advertisement for its existence and
connected as well via linking attribute AdvertiserID. By reviewing FDs, it is clear
that the table is in BCNF form so no further normalisation required.
● Advertisement
Advertisement (AdvertisementID, AdvertiserID, BoardID, Contract Period
(StartDate, EndDate), Fees, Description)
AdvertisementID → AdvertiserID, BoardID, Contract Period, Fees, Description
▪ Analysis:
Advertisement entity set is dependent on Advertiser for its existence and
connected as well via linking attribute AdvertiserID. By reviewing FDs it is clear
that the table is in BCNF form so no further normalisation required.
5.1.14 Services and Contracts
● Services
Service (ServiceID, ServiceFor, ProviderID, Description, Contract Period (StartDate,
EndDate))
ServiceID → ServiceFor, ProviderID, Description, Contract Period
▪ Analysis:
ServiceID entity set will list Drinking Water details which were using in the
mall. ServiceID is unique so it is the candidate key in the entity set. By looking
additional normalisation
● Service Providers/ Seller- For Goods

Provider (ProviderID, ROID, RepresentativeID, Description)
ProviderID → ROID, RepresentativeID, Description
▪ Analysis:
ProviderID entity set will list Drinking Water details which were using in the
mall. ProviderID is unique so it is the candidate key in the entity set. By looking
5.1.15 Infrastructure and Other
● Promotional Temporary shops

TempShop (TempShopID, ShopFor, OperatorID, RepresentativeID, Description,
Period (StartDate, EndDate))
TempShopID → ShopFor, OperatorID, RepresentativeID, Description, Period
▪ Analysis:
TempShopID entity set will list Drinking Water details which were using in the
mall. TempShopID is unique so it is the candidate key in the entity set. By looking
● Trees and Plants

Trees (TreeName, Numbers, Indoor/Outdoor)
TreeName → Numbers, Indoor/Outdoor
▪ Analysis:
6 IMPLEMENTATION
The feasibly of the data model can be demonstrated by running sample queries in
relational algebra and SQL. We have used the RelaX - relational algebra calculator
platform to create the database, populating it with dummy data and running the
ReAlg and SQL queries. The dummy data, queries and outputs can be found below.
Dummy Data
Phone_
RPID name Gender DOB State Email_Id
number
'RP_0001' 'Govardhan' 'Male' '02/03/1996' 'Telangana' 8903384682 'Govardhan123@gmail.com'
'RP_0002' 'Manish' 'Male' '04/06/1981' 'Andhra Pradesh' 6848866489 'Manish_mal@gmail.com'
'RP_0003' 'Shrikanth' 'Male' '06/07/1980' 'Madhyapradesh' 8902787462 'shri@yahoo.in'
'RP_0004' 'Raji' 'Female' '02/06/1988' 'Tamilnadu' 7890387463 'raji23@gmai.com'
'RP_0005' 'Mousa' 'Male' '09/01/1990' 'Bihar' 9003874628 'Mousa@yahooo.in'
'RP_0006' 'Abdul' 'Male' '08/01/1980' 'Delhi' 9048982676 'Abdul@gmail.com'
'RP_0007' 'Sunil' 'Male' '08/06/1995' 'Karnataka' 8938746274 'sunil224@gmail.com'
'RP_0008' 'Krish' 'Male' '22/03/1979' 'Gujarat' 6847200482 'Krish278@yahoo.com'
'RP_0009' 'Marcel' 'Male' '21/05/1991' 'Punjab' 6849028748 'Marcellus2028@gmail.com'
'RP_0010' 'Ram' 'Male' '18/11/1992' 'Uttarpradesh' 9098625479 'Ram@gmail.com'
'RP_0011' 'Klaus' 'Male' '20/12/1988' 'Tamilnadu' 8902846268 'Klaus1000@gmail.com'
'RP_0012' 'Elijah' 'Male' '28/05/1975' 'Maharasthra' 7820044862 'Elijah1004@gmail.com'
'RP_0013' 'Rebekah' 'Female' '06/06/1980' 'Punjab' 8745627902 'Rebekah998@gmail.com'
'RP_0014' 'Vishali' 'Female' '24/02/1978' 'Orissa' 8018465628 'Vishali224@yahoo.com'
'RP_0015' 'Preran' 'Male' '21/03/1976' 'Rajasthan' 6536820009 'preran@gmail.com'
'RP_0016' 'Camile' 'Female' '30/08/1974' 'Karnataka' 9019846629 'cami1990@gmail.com'
6.1.2 Shop Details
Monthly_
Shop_ID Property_ID Revenue Revenue_sharing_per
maintenance
'SH_0001' 'PR_0001' 500000 8000 7
'SH_0002' 'PR_0002' 600000 6000 8.95
'SH_0003' 'PR_0003' 400000 4500 6.34
'SH_0004' 'PR_0004' 350000 7600 4.98
'SH_0005' 'PR_0005' 450000 9200 8.85
'SH_0006' 'PR_0006' 355000 8260 6.63
'SH_0007' 'PR_0007' 320000 8660 8
'SH_0008' 'PR_0008' 285000 9060 4.5
'SH_0009' 'PR_0009' 250000 9460 3.5
'SH_0010' 'PR_0010' 215000 9860 3.25
'SH_0011' 'PR_0011' 180000 3600 4
'SH_0012' 'PR_0012' 145000 4800 2.5
'SH_0013' 'PR_0013' 110000 7200 2.5
'SH_0014' 'PR_0014' 75000 2500 3
'SH_0015' 'PR_0015' 40000 4300 2
'SH_0016' 'PR_0016' 505500 4210 9
'SH_0017' 'PR_0017' 330000 4120 7.5
'SH_0018' 'PR_0018' 440000 4030 7.5
6.1.3 Property Owned
property_ID Owner_ID Date_trxn Stake_per Representative_ID

'PR_0001' 'OW_0001' '27-11-2018' 7 'Rep_ID_0001'
'PR_0002' 'OW_0002' '28-07-2019' 8.95 'Rep_ID_0002'
'PR_0003' 'OW_0003' '30-12-2020' 6.34 'Rep_ID_0003'
'PR_0004' 'OW_0002' '01-06-2016' 4.98 'Rep_ID_0002'
'PR_0005' 'OW_0004' '12-08-2019' 8.85 'Rep_ID_0004'
'PR_0006' 'OW_0001' '20-06-2016' 6.63 'Rep_ID_0005'
'PR_0007' 'OW_0005' '21-08-2015' 8 'Rep_ID_0006'
'PR_0008' 'OW_0006' '17-12-2018' 4.5 'Rep_ID_0007'
'PR_0009' 'OW_0007' '20-10-2018' 3.5 'Rep_ID_0008'
'PR_0010' 'OW_0006' '15-08-2009' 3.25 'Rep_ID_0007'
'PR_0011' 'OW_0008' '28-09-2008' 4 'Rep_ID_0009'
'PR_0012' 'OW_0009' '06-07-2019' 2.5 'Rep_ID_0010'
'PR_0013' 'OW_0010' '09-12-2020' 2.5 'Rep_ID_0011'
'PR_0014' 'OW_0009' '03-04-2021' 3 'Rep_ID_0010'
'PR_0015' 'OW_0009' '19-06-2017' 2 'Rep_ID_0012'
'PR_0016' 'OW_0004' '21-08-2020' 9 'Rep_ID_0013'
'PR_0017' 'OW_0011' '15-12-2018' 7.5 'Rep_ID_0014'
'PR_0018' 'OW_0012' '19-09-2009' 7.5 'Rep_ID_0015'
6.1.4 Parking Slot
Parking_ID Section_ID Type

'PR_0001' 'Sec_A' '2'
'PR_0002' 'Sec_A' '2'
'PR_0003' 'Sec_A' '4'
'PR_0004' 'Sec_A' '4'
'PR_0005' 'Sec_B' '2'
'PR_0006' 'Sec_B' '2'
'PR_0007' 'Sec_B' '4'
'PR_0008' 'Sec_B' '4'
'PR_0009' 'Sec_C' '2'
'PR_0010' 'Sec_C' '2'
'PR_0011' 'Sec_C' '4'
'PR_0012' 'Sec_C' '4'
'PR_0013' 'Sed_D' '2'
'PR_0014' 'Sed_D' '2'
'PR_0015' 'Sed_D' '4'
'PR_0016' 'Sed_D' '4'
6.1.5 Visitor
Visitor_ Body Phone

Visitor_ID Name Age Intime Outtime Date
Grp_ID temp number
'VID_0001' 'VG_0001' 'Krish' 19 98.8 8768999897 '10:30' '11:30' '26-06-2021'
'VID_0002' 'VG_0001' 'Mukund' 20 98.6 8648048394 '10:30' '11:30' '26-06-2021'
'VID_0003' 'VG_0002' 'Kol' 26 98.4 6644445678 '11:00' '12:00' '26-06-2021'
'VID_0004' 'VG_0002' 'Mason' 36 98.9 7847729947 '11:00' '12:00' '26-06-2021'
'VID_0005' 'VG_0003' 'Tyler' 20 98.06 9927646782 '12:00' '13:00' '27-06-2021'
'VID_0006' 'VG_0003' 'Mahesh' 40 99.2 9736678593 '12:00' '13:00' '27-06-2021'
'VID_0007' 'VG_0004' 'Pawan' 60 99.04 6847626744 '13:00' '14:00' '27-06-2021'
'VID_0008' 'VG_0004' 'Charan' 43 99.01 8580068847 '13:00' '14:00' '28-06-2021'
'VID_0009' 'VG_0005' 'Vijay' 23 98.3 8886789485 '13:30' '14:00' '29-06-2021'
'VID_0010' 'VG_0005' 'Ram' 28 98.34 7869987475 '13:30' '14:30' '30-06-2021'
'VID_0011' 'VG_0005' 'Nikhil' 26 98.78 8960947786 '13:30' '14:30' '01-07-2021'
'VID_0012' 'VG_0006' 'Harsha' 32 98.67 9087476689 '14:00' '14:30' '02-07-2021'
'VID_0013' 'VG_0007' 'Tej' 42 98.1 9875794767 '14:25' '15:00' '02-07-2021'
'VID_0014' 'VG_0007' 'Varun' 32 98.2 8576478764 '14:25' '15:00' '02-07-2021'
'VID_0015' 'VG_0008' 'Dharam' 23 97.9 7745378576 '15:00' '16:00' '02-07-2021'
'VID_0016' 'VG_0009' 'Chiranjeevi' 56 98.28 7456388563 '15:00' '16:00' '03-07-2021'
'VID_0017' 'VG_0010' 'Salaman' 65 99.04 9857658744 '15:35' '16:00' '03-07-2021'
'VID_0018' 'VG_0011' 'Sharukh' 58 99.12 7466295746 '15:35' '17:00' '03-07-2021'
'VID_0019' 'VG_0012' 'Damon' 22 99.24 6589503756 '16:00' '17:00' '03-07-2021'
'VID_0020' 'VG_0012' 'Matt' 20 98.49 8563685973 '16:00' '17:00' '03-07-2021'
6.1.6 Visitor Vehicle
Vehicle_Number Parking_ID Intime Outitme Visitor_ID INTrxnID

'CS_8573' 'PR_0001' '10:30' '11:30' 'VID_0001' 'IN_0001'
'BG_9747' 'PR_0002' '11:00' '12:00' 'VID_0003' 'IN_0002'
'BF-4957' 'PR_0005' '12:00' '13:00' 'VID_0005' 'IN_0003'
'JH_9457' 'PR_0006' '13:00' '14:00' 'VID_0007' 'IN_0004'
'RE_9485' 'PR_0007' '13:30' '14:00' 'VID_0010' 'IN_0005'
'FR_9585' 'PR_0009' '14:00' '14:25' 'VID_0012' 'IN_0006'
'BF_8473' 'PR_0011' '14:25' '15:00' 'VID_0014' 'IN_0007'
'CD_9474' 'PR_0013' '15:00' '16:00' 'VID_0016' 'IN_0008'
'HG_9584' 'PR_0015' '15:35' '17:00' 'VID_0017' 'IN_0009'
'HT_9584' 'PR_0016' '15:35' '17:00' 'VID_0018' 'IN_0010'
'GF_9478' 'PR_0004' '16:00' '17:00' 'VID_0020' 'IN_0011'
6.1.7 Employee Details
Emp_ID category SE_ID Type DOJ Salary RPID

'EID_0001' 'Security' 'SEID_0001' 'Direct' '27-11-2018' 15000 'RP_0001'
'EID_0002' 'Security' 'SEID_0002' 'Contracted' '28-07-2019' 13000 'RP_0002'
'EID_0003' 'Cleaner' 'SEID_0001' 'Direct' '30-12-2020' 15000 'RP_0003'
'EID_0004' 'CLeaner' 'SEID_0002' 'Contracted' '01-06-2016' 13000 'RP_0004'
'EID_0005' 'SalesMan' 'SEID_0001' 'Direct' '12-08-2019' 20000 'RP_0005'
'EID_0006' 'SalesMan' 'SEID_0002' 'Contracted' '20-06-2016' 20000 'RP_0006'
'EID_0007' 'Cashier' 'SEID_0001' 'Direct' '21-08-2015' 25000 'RP_0007'
'EID_0008' 'Cashier' 'SEID_0002' 'Contracted' '17-12-2018' 24000 'RP_0008'
'EID_0009' 'Cashier' 'SEID_0001' 'Direct' '20-10-2018' 25000 'RP_0009'
'EID_0010' 'Cashier' 'SEID_0002' 'Contracted' '15-08-2009' 24000 'RP_0010'
'EID_0011' 'Finance' 'SEID_0001' 'Direct' '28-09-2008' 28000 'RP_0011'
'EID_0012' 'Finance' 'SEID_0002' 'Contracted' '06-07-2019' 28000 'RP_0012'
'EID_0013' 'Manager' 'SEID_0001' 'Direct' '09-12-2020' 35000 'RP_0013'
6.1.8 Property Details
Property_ID Property_number Floor Area Description

'PR_0001' '101' 1 2500 'Property-1'
'PR_0002' '102' 1 2500 'Property-2'
'PR_0003' '103' 1 3000 'Property-3'
'PR_0004' '104' 1 3000 'Property-4'
'PR_0005' '201' 2 2500 'Property-5'
'PR_0006' '202' 2 2500 'Property-6'
'PR_0007' '203' 2 3000 'Property-7'
'PR_0008' '204' 2 3000 'Property-8'
'PR_0009' '301' 3 2500 'Property-9'
'PR_0010' '302' 3 3000 'Property-10'
'PR_0011' '303' 3 2500 'Property-11'
'PR_0012' '304' 3 3000 'Property-12'
'PR_0013' '401' 4 2500 'Property-13'
'PR_0014' '402' 4 3000 'Property-14'
'PR_0015' '403' 4 2500 'Property-15'
'PR_0016' '404' 4 3500 'Property-16'
'PR_0017' '501' 5 5000 'Property-17'
'PR_0018' '502' 5 5000 'Property-18'
Relational Algebra
6.2.1 Find the Shop_ID and Property_ID of those shops which are on 4 th floor
and having Owner with OwnerID OW_0004.
Query:
π Shop_ID, Property_ID (σ Floor=4 ∧ Owner_ID= 'OW_0004' (SHOP_DETAILS ⨝
(PROPERTY_DETAILS ⨝ property_Owned)))
Screenshot:
Output:
6.2.2 Find the VisitorID and Vehicle number of visitors who has their 2-
wheeler parked in section-B
Query:
π Visitor_ID, Vehicle_Number (σ Type='2' ∧ Section_ID= 'Sec_B' (VISITOR ⨝
(VISITOR_VEHICLE ⨝ PARKING_SLOT)))
Screenshot:
Output:
6.2.3 Find the IDs of recognised persons who are in the cashier position and
are contracted.
Query:
π RPID (σ category='Cashier' ∧ Type= 'Contracted' (Recognized_persons ⨝
Employee_Details))
Screenshot:
Output:
6.2.4 Find the list of all owners who has a stake in more than one property
and has the same Representative for at least two of them.
Query:
π p1.Owner_ID (σ (p1.Property_ID ≠ p2.Property_ID) ∧(p1.Representative_ID =
p2.Representative_ID) ∧ (p1.Owner_ID=p2.Owner_ID) ( ρ p1 (property_Owned)
⨯ ρ p2 (property_Owned)) )
Screenshot:
Output:
6.2.5 Find the list of employees who are of same category and have more
salary than the other.
Query:
π e1.Emp_ID, e2.Emp_ID (σ (e1.category = e2.category) ∧(e1.Salary >
e2.Salary) ( ρ e1 (Employee_Details) ⨯ ρ e2 (Employee_Details)) )
Screenshot:
Output:
SQL
6.3.1 Find the Shop_ID and Property_ID of those shops on the 4th floor and
have Owner with OwnerID OW_0004.
Query:
SELECT SHOP_DETAILS.Shop_ID,SHOP_DETAILS.Property_ID
FROM
SHOP_DETAILS NATURAL JOIN PROPERTY_DETAILS NATURAL JOIN Property_Owned
WHERE Property_Owned.Owner_ID = 'OW_0004' AND PROPERTY_DETAILS.Floor = 4;
Screenshot:
Output:
6.3.2 Find the VisitorID and Vehicle number of visitors who has their 2-
wheeler parked in section-B
Query:
SELECT VISITOR.Visitor_ID, VISITOR_VEHICLE.Vehicle_Number
FROM VISITOR NATURAL JOIN VISITOR_VEHICLE NATURAL JOIN PARKING_SLOT
WHERE PARKING_SLOT.Type = '2' AND PARKING_SLOT.Section_ID = 'Sec_B';
Screenshot:
Output:
6.3.3 Find the IDs of recognised persons who are in the cashier position and
are contracted.
Query:
SELECT Recognized_persons.RPID
FROM Recognized_persons NATURAL JOIN Employee_Details
WHERE Employee_Details.category = 'Cashier' AND Employee_Details.Type =
'Contracted';
Screenshot:
Output:
6.3.4 Find the list of all owners who have a stake in more than one property
and have the same Representative for at least two of them.
Query:
SELECT p1.Owner_ID
FROM Property_Owned AS p1, Property_Owned AS p2
WHERE p1.Property_ID != p2.Property_ID AND p1.Representative_ID =
p2.Representative_ID AND p1.Owner_ID = p2.Owner_ID;
Screenshot:
Output:
6.3.5 Find the list of employees who are of the same category and have
more salary than the other.
Query:
SELECT e1.Emp_ID ,e2.Emp_ID
FROM Employee_Details AS e1, Employee_Details AS e2
WHERE e1.category = e2.category
AND e1.Salary > e2.Salary;
Screenshot:
Output:
7 OUR LEARNINGS
During the course of this project, we have learnt quite a few things. Most important of
all was the development of the skills specific to collaborative efforts and
communication.
In this project, we have chosen to work on Shopping Mall Database Model. In order
to try to make this model as accurate and practical as possible, we had extensively
researched how a shopping mall works and tried to grasp all the aspects on which a
successful Mall is built. This itself increased the communications between the members
of the group and broadened our mind. This also helped us identify entity sets and
attributes that would be used to build a good database model. All our knowledge will
undoubtedly assist us in the future.
Drawing the ER Model was a difficult task as incorporating so many entities set into it
was complex. Also creating tables and inserting data into them, was though a tedious
work, it was a huge practice for us. Trying to incorporate various things in our queries
was especially a fun part as we ourselves had to think of a problem and try to make
query to solve that. Nonetheless, after completing it, we had an even more precise
image of our data-model looks and how the ER diagram helped us visualise the
database design.
Besides the technical and conceptual knowledge and understanding, we learned

things like time management, group work, planning, which were the critical points in
the completion of this project. These are important not only in this project but
throughout life. These things will surely help us throughout our life.
8 REFERENCES
• Amanora Shopping Mall, Pune

https://www.amanoramall.com/
• Kumar Pacific Mall, Pune

http://www.kumarpacificmall.com/
• RelaX - relational algebra calculator

https://dbis-uibk.github.io/relax/landing
• ER Diagram Drawing Tool

https://draw.io/
• ER Diagram Web URL

https://ibb.co/S5qS9W8
• Reference Articles
http://users.csc.calpoly.edu/~jdalbey/205/Lectures/HOWTO-ERD.html
http://www.cis.drexel.edu/faculty/song/courses/info%20605/appendix/Appe
ndixA.PDF

A Complete Database Design For Shopping Mall

Uploaded by

Copyright:

Available Formats

You might also like

A Complete Database Design For Shopping Mall

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Complete Database Design For Shopping Mall

Uploaded by

Copyright:

Available Formats

SHOPPING ABV-IIITM

A Complete Database Design By

For Shopping Mall Ramesh Reddy

Shopping Mall Database

Under The Guidance Of

With Western lifestyle being portraited as modern way of leaving, popularity of

Through this Database Management Project, we have made an attempt to design

Why we chose this topic?

Recognised persons and Recognised organisations are a generalisation of all the

3.1.1 Recognised Persons

Notes, Logic and Rules:

1. Every RP must have specific information

3.1.2 Recognised Organisation:

Notes, Logic and Rules:

1. As an organisation can have multiple representatives for different purposes, we

2. Every RO must have specific information

3.1.3 Mall Employees:

Notes, Logic and Rules:

1. Manager with no further managers will have their own EmployeeID as

3.1.4 Owner, Operator and Representative

Notes, Logic and Rules:

1. We made separate Owner, Operator and Representative tables instead of

assigned ROID or RPID in the tables Property Owned by and Property

3.1.5 Property, It's ownership and operator:

Notes, Logic and Rules:

● Ownership, and Representative (Authorised person from owner)

Property Owned by (PropertyID, OwnerID, DateOfStakeTrxn, Stake %,

● Operation and Representative (Authorised person from operator)

3.1.6 Visitors and Parking:

Notes, Logic and Rules:

Notes, Logic and Rules:

1. Each asset has a different AssetID.

3.1.8 Shop Details:

Notes, Logic and Rules:

3.1.9 Shop Employees:

Notes, Logic and Rules:

● Shop Employee Details

3.1.10 Meter Details:

Notes, Logic and Rules:

1. Records electricity and water usages

● Electricity Meter Details

● Drinking Water Meter

● Normal Water Meter

3.1.11 Mall Anonymous - Lists

Mall electricity meters

Mall Drinking Water Meter

Mall Normal Water Meter

Notes, Logic and Rules:

1. All transactions will be divided in three categories- Payments Received,

● Inward Transaction Details

● Outward Transaction Details

3.1.13 Advertising Management

Notes, Logic and Rules:

1. In table "Advertisement Board":

3.1.14 Services and Contracts

Notes, Logic and Rules:

1. The Service Provider/Contractor is an organisation.