0% found this document useful (0 votes)
2 views

Data dictionary (5)

The document outlines a database assignment focused on creating an entity-relationship diagram and data dictionary for a retail system, detailing entities such as Customer, Bank, Product, Purchase, Stock, Store, and Order. It specifies functional dependencies, normalization processes to achieve 3NF, and includes SQL code for user roles and security management. Additionally, it discusses security measures like Transparent Data Encryption and PL/SQL source code protection.

Uploaded by

Houda Ar
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views

Data dictionary (5)

The document outlines a database assignment focused on creating an entity-relationship diagram and data dictionary for a retail system, detailing entities such as Customer, Bank, Product, Purchase, Stock, Store, and Order. It specifies functional dependencies, normalization processes to achieve 3NF, and includes SQL code for user roles and security management. Additionally, it discusses security measures like Transparent Data Encryption and PL/SQL source code protection.

Uploaded by

Houda Ar
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 12

DATABASE ASSIGNMENT houda aoussar

ENTITY DIAGRAM:

The order entity is for


optimisation. For
example: If someone
bought 30 products
from the same store
there is not need to
rewrite the date and
the store 30 times

Data dictionary:

Customer
Attribute name Data type Length Required Format PK FK
Costomer_id Number 10 Y Y
Name VARCHAR 100 Y
Address VARCHAR 100 Y
Phone_number VARCHAR 100 Y
Date_of_birth DATE YYYY-MM-DD
Bank_detail_id NUMBER 10 Y Bank. Bank_detail_id

Bank
Attribute name Data type Length Required Format PK FK
Bank_detail_id Number 10 Y Y
Bank_Name VARCHAR 100 Y
Address VARCHAR 100 Y
SortCode VARCHAR 100 Y
AccountNumbe VARCHAR 100 Y

Product
Attribute name Data type Length Required Format PK FK
Product_ID Number 10 Y Y
Product_Type VARCHAR 100 Y
Product_Name VARCHAR 100
Product_Description VARCHAR 100
P_UnitPrice VARCHAR 100 99999.99

Purchase
Attribute name Data type Length Required Format PK FK
Purchase_ID Number 10 Y Y
Customer_id VARCHAR 10 Y Customer.customer_id
Store_id VARCHAR 10 Y Store.store_id
Date_of_purchase DATE YYYY-MM-DD

Stock
Attribute name Data type Length Required Format PK FK
Store_id Number 10 Y Store.store_id
Product_id Number 10 Y Product.product_id
Quantity Number

Store
Attribute name Data type Length Required Format PK FK
Store_id Number 10 Y Y
Store_name Varchar 10 Y
Store_address Varchar 100

Order
Attribute name Data type Length Required Format PK FK
Order_id Number 10 Y Y
Product_id Number 10 Y Product.product_id
Purchase_id Number 10 Y Purchase.purchase_id
Quantity Number
The order table is added for optimization: For example, if a customer just orders 30 products, we do
not need to rewrite the date and the store

SPECIFICATION OF FDs :

CUSTOMER:
customer_id → name, address, telephone_number, date_of_birth, bank_detail_id
( bank_detail_id is a foreign key linking to the BankDetail entity) .
BANK DETAIL:
bank_detail_id → bank_name, address, sort_code, account_number.
PRODUCT:
product_id → type, name, description, cost.
Each product has a unique product id.
PURCHASE:
purchase_id → date_of_purchase, customer_id, store_id.
ORDER:
order_id → purchase_id, product_id, quantity, unit_price.
STOCK:
(product_id, store_id) → quantity.
The combination of product ID and store ID uniquely determines the stock quantity.
Store:
store_id → name, address.
Each store is unique and has a unique ID.

To justify The 3NF :


First Normal Form: Each table has its own primary and all columns contain values of
atomic data type.
Second Normal Form: All tables are in 1NFm in addition , all candidate key are dependent
upon the whole key.
Third Normal Form: All table are in 2NF , in addition , all non-key columns are directly
dependent only upon the key or every key for the stock table for example.
TO resolve the many-to-many relationships between the store and the product we have
created a table named stock that will contain the primary key of the product and primary
key of the store.
The Order table is an optimization strategy for managing sales transactions efficiently. It
allows the database to handle complex purchase operations and reporting requirements
more effectively.

SQL CODE SCREENSHOT AND EXPLAINATION:

If table exists already you will get an error. That is why we drop all tables first.

The we create them:


Inserting values for each tables.
PL/SQL :
New customer registrations instance :
Successful
registration for new
customer

Making purchase
process :

NEW PURCHASE :
Product iD NOT FOUND
Insufficient stock for
the selected product :

Report management

Security Management Report


Oracle Database provides a rich set of default security features to manage user accounts,
authentication, privileges, application security, encryption, network traffic, and auditing. To
manage the different user types :

By default, Oracle relational database management system does not give any privileges to new
users.
New roles are created using The CREATE ROLE statement:

Manager's Administration : The manager will be able to view and edit all the database,
privileges are added to roles using the GRANT statement.

CREATE ROLE manager_role ;

GRANT SELECT, INSERT, UPDATE, DELETE ON CUSTOMER TO manager_role;


We have done the same thing to all tables.

Finance Staff's Administration: The finance staff will be able to access all customers' data and
edit it.

CREATE ROLE finance_role;


GRANT SELECT, UPDATE ON CUSTOMER TO finance_role;
Registered customers: The registered Customers will be able to view products and make
purchase

CREATE ROLE regitered_customer_role;


GRANT SELECT ON PRODUCT TO regitered_customer_role;
GRANT INSERT ON PURCHASE , “ORDER “ TO regitered_customer_role;
Unregistered customers: The unregistered Customers will be able to view available products
only.

CREATE ROLE Unregitered_customer_role;


GRANT SELECT ON PRODUCT TO Unregitered_customer_role;
Also, we will create new accounts for users with a unique username and password.

This account is the system that the user will be interacting with.

The sql code:

CREATE USER manager1 IDENTIFIED BY "sLF$bYY69xyz";

CREATE USER finance_staff1 IDENTIFIED BY "M#F[JHy5fxyz";

CREATE USER finance_staff2 IDENTIFIED BY "Tw6YU9B=Sxyz";

CREATE USER finance_staff3 IDENTIFIED BY "j=BkW77JMxyz";


CREATE USER registered_customer IDENTIFIED BY "BR3>=b~GGxyz";

GRANT manager_role TO manager1;

GRANT finance_role TO finance_staff1;

GRANT finance_role TO finance_staff2;

GRANT finance_role TO finance_staff3;

GRANT registered_customer_role TO registered_customer ;

We can add other security measures like:

Transparent Data Encryption for sensitive data such as customer bank details.
We have to use the encryption key (password that serves to encrypt and decrypt your data). The
process of encryption is transparent to customers.
Wrapping is the process of hiding PL/SQL source code. Wrapping helps developers to protect their
source code from any user who can benefit or might misuse it.

To protect PL/SQL objects is necessary to disable DDL statements like create, replace and some
DML statements oriented to the static data dictionary views *_SOURCE.
To implement this method in our database, we can:

Encrypt our database PL/SQL source code using Oracle's wrap utility before deploying it to the
database.
REFERENCES:

BOOKS: PROTECTING ORACLE PL/SQL SOURCE CODE FROM A DBA USER , Hakik Paci, Elinda Kajo
Mece, Aleksander Xhuvani1 - Polytechnic University of Tirana
The database book, principles and practice using the ORACLE database system , DR NARAIN
GENANI.

Reference from internet : https://docs.oracle.com/


ALL materials from the course database.

You might also like