Database Systems and Design

Stage 1: Scenario and Conceptual Database Design.

Task 1: Selection of the case upon which the database design and
implementation is to be based

Scenario

According to a case study of XYZ organisation, either new and existing

organisations will frequently base their plans on the response they provide. It's a
difficult topic to answer, mostly since both sides of the political divide bring
compelling reasons to the table. The current business trend, especially among
technology firms, is to encourage generality as corporations aim to incorporate
with many features and functionality as feasible. As they pursue new consumers,
some businesses, such as Facebook, are literally breaking out from what makes
them so great in the first place. Is this, however, the right course of action, or are
corporations better off pursuing a specialisation strategy? While this discussion
has raged for decades, it was reignited recently when Spotify announced that it
would expand its internet streaming services to include additional features such
as video content and podcasting. Spotify has, of course, established itself as a
major force in the streaming music industry, rivalling Pandora in terms of
market size. Many people are asking whether Spotify's desire to be more
generalist in their offerings is the proper strategy to pursue.

Each method has its own set of disadvantages. As new products and services are
produced and deployed, generalisation may lead to more sophisticated
procedures. And, as one might expect, the more diverse a business's offers are,
the less effective it is. Specialization, on the other hand, has a significant
disadvantage. As previously said, focusing on fewer benefits means placing all of
one's eggs in one basket. A technique like this provides less security.
As shown in above figure, the conceptual design comprises of two parallel tasks.
The first process entails designing the database's collected data, structure, and
restrictions, while the second entails designing database applications. We have
omitted illustrating most of the connections between these parties to keep the
graphic simple, although the two activity is closely connected. We can discover
collected data which will be saved in the database, for instance, by examining
application software. Furthermore, the physical database concept design,
wherein the we pick the data stores and access pathways for data blocks, is
influenced by the programs that will search and update these files. The six
phases stated above are not always followed in that order. We may need to
change the design from such an earlier stage at a late stage in many cases.
Feedback loops between phases, as well as within stages, are frequent. We only
display a few feedback mechanisms  although there are many more across
phases. We've also depicted some connection here between data processing sides
of the diagram; in fact, there are many more interconnections. It  entails
collecting intelligence about the application's intended usage, whereas Phase 6
deals with database deployment and redesign. Phases 2, 4, and 5 are at the heart
of the personal information design process; we'll go through them briefly.

Task 2: Provide a conceptual database design for your scenario & the list of
enterprise rules being modelled.

Entity Relationship (ERD) stands for Entity Relationship Model. Entity refers to
a state's object; in most cases, we referred to an item as a data store. The e-r
diagram represents the relationship among each graph database. The E-R
diagram depicts an item with characteristics, which are characteristics of the
entity. If the object is a sql table, and all of the seat's fields are considered
attributes.

Stage 2: Logical Database Design and Oracle SQL Implementation/querying

Task 3: Provide a Logical Database Design for your scenario

Databases design is the act of converting (or mapping) a software produces into a
pattern for the database table supporting a given DBMS, including the
conventional or element database schema. This mapping could be viewed as the
result of trying to meet two different types of goals: I management information
objectives: overcoming challenges linked to the ease and cost of obtaining a
linear, as well as the costs of managing and storing restrictions; (ii) Truly
representative goal: preserving the ability to record and recognize all valid entity
relationship model combinations;
Task 4: Create the tables using Oracle DBMS

Task 5: Create the four most useful indexes on your tables

Task 6: Data Population

Task 7: SQL Query writing

1st query

2nd query

3rd query
4th query

5th query

Stage 3: Argument

Task 8

A durable database is a type of system that holds files in the form of materials or
entries that seem to be durable across equipment and applications. Data that is
persistent is both stable and accessible. Traditional computer operating systems
(RDBMS) use records and columns to retain stored information. There is a centralized
set of data in the relational method, which not only helps to avoid wasting data
storage and also helps to regulate redundancies through data integration. It avoids
redundant work by employing techniques such as normalisation and key ideas.

Stage 4: Evaluation Of different data models

Task 9

The Data Model depicts how the final product will look once it has been widely
deployed. It specifies both the data pieces and the relationships between them. Data
warehouses are being used to indicate wherever information is kept, accessed,
searchable, and modified in a database management system. We present the data in a
system of symbols and words so that all members of the organisation can grasp and
interpret it. However, there are various methods in use nowadays, the most common
of which is the traditional relational model.

References

Zhang, B., Van Aken, D., Wang, J., Dai, T., Jiang, S., Lao, J., Sheng, S., Pavlo, A.
and Gordon, G.J., 2018. A demonstration of the ottertune automatic database
management system tuning service. Proceedings of the VLDB Endowment, 11(12),
pp.1910-1913.

Yu, X., Xia, Y., Pavlo, A., Sanchez, D., Rudolph, L. and Devadas, S., 2018. Sundial:
harmonizing concurrency control and caching in a distributed oltp database
management system. Proceedings of the VLDB Endowment, 11(10), pp.1289-1302.
Widianto, S.R., Sudiro, S.Y., Suwandi, I. and Leiliawati, L., 2020. Database
Management System on Raw Material Transaction System Case Study: Sabana Fried
Chicken. Jurnal Mantik, 4(3), pp.1722-1727.