0% found this document useful (0 votes)
35 views7 pages

Home w3

The document discusses database system concepts and architecture. It describes different types of users for a university database including registration office users, admissions office users, and transcripts office users. It also discusses choosing a three-tier client/server architecture for a web-based airline reservation system.

Uploaded by

bero.b.swift
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
35 views7 pages

Home w3

The document discusses database system concepts and architecture. It describes different types of users for a university database including registration office users, admissions office users, and transcripts office users. It also discusses choosing a three-tier client/server architecture for a web-based airline reservation system.

Uploaded by

bero.b.swift
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Chapter 2: DATABASE SYSTEM CONCEPTS AND ARCHITECTURE

CHAPTER 2: DATABASE SYSTEM CONCEPTS AND ARCHITECTURE Answer the


following questions: 2.1 - Think of different users for the database of Figure 1.2. What type of
applications would each user need? To which user category would each belong and what type of
interface would they need?

(a) Registration Office User: They


can enter data that reflect the
registration of students in
sections of courses, and later enter
the grades of the students.
Applications can include:
- Register a student in a section of a
course
(a) Registration Office User: They
can enter data that reflect the
registration of students in
sections of courses, and later enter
the grades of the students.
Applications can include:
- Register a student in a section of a
course
(a) Registration Office User: They
can enter data that reflect the
registration of students in
sections of courses, and later enter
the grades of the students.
Applications can include:
- Register a student in a section of a
course
(a) Registration Office User: They
can enter data that reflect the
registration of students in
sections of courses, and later enter
the grades of the students.
Applications can include:
- Register a student in a section of a
course
(a) Registration Office User:
They can enter data that reflect the
(a) Registration Office User: They
can enter data that reflect the
registration of students in
sections of courses, and later enter
the grades of the students.
Applications can include:
- Register a student in a section of a
course
(a) Registration Office User: They
can enter data that reflect the
registration of students in
sections of courses, and later enter
the grades of the students.
Applications can include:
- Register a student in a section of a
course
(a) Registration Office User: They
can enter data that reflect the
registration of students in
sections of courses, and later enter
the grades of the students.
Applications can include:
- Register a student in a section of a
course
(a) Registration Office User: They can enter data that reflect the registration of students
in sections of courses, and later enter the grades of the students. Applications can
include:
- Register a student in a section of a course
- Check whether a student who is registered in a course has the appropriate prerequisite
courses
- Drop a student from a section of a course
- Add a student to a section of a course
- Enter the student grades for a section
Application programmers can write a number of canned transactions for the registration
office end-users, providing them with either forms and menus, or with a parametric
interface.

(b) Admissions Office User: The main application is to enter newly accepted students into
the database. Can use the same type of interfaces as (a).

(c) Transcripts Office User: The main application is to print student transcripts.
Application programmers can write a canned transaction using a report generator utility
to print the transcript of a student in a prescribed format. The particular student can be
identified by name or social security number. Another application would be to generate
grade slips at the end of each semester for all students who have completed courses
during that semester. Again, this application could be programmed using a report
generator utility.
2.2 - if you were designing a Web-based system to make airline reservations and to sell airline
tickets, which DBMS Architecture would you choose? Why? Why would the other architectures
not be a good choice?
Three-Tier Client/Server Architecture for Web Application is the best choice. The Client consists of
Web User Interface. The Web Server contains the application logic which includes all the rules and
regulations related to the reservation process and the issue of tickets; the Database Server contains
the DBMS.

Centralized DBMS Architecture would not work since the user interface and database server are on
different machines for a web-based system.

Basic Client/Server Architecture and 2.5.3 Two-Tier Client/Server Architecture would work if the
Business Logic can reside on server other than the DBMS Server. In general, if the business logic
was on the DBMS Server, it will put an excessive burden on the server. If the business logic were to
reside on the web client, it will burden the communication network as well a possibly thin client
1. Consider Figure 2.1. In addition to constraints relating the values of columns in one table to columns in
another table, there are also constraints that impose restrictions on values in a column or a
combination of columns within a table. One such constraint dictates that a column or a group of
columns must be unique across all rows in the table. For example, in the STUDENT table, the
Student_number column must be unique (to prevent two different students from having the same
Student_number). Identify the column or the group of columns in the other tables that must be unique
across all rows in the table.

Sl.no Table Column/Columns Constrains


1. STUDENT Student_number -Student number should be unique
across all rows in the table to avoid
overlapping of the tables if any two
students have same names in a
section.
2. COURSE Course_number -No two course number can be same,
course number determines the
department and course name itself.
-If any new course is added to the
catalog then it must be assigned a
unique number to differentiate from
the existing ones.
3. PREREQUISITE Prerequisite_number - Prerequisites are unique because
they depend on the course in the
section table.
-Few courses have prerequisites, few
don’t so it is really important to make
sure that Prerequisite_number is
unique.
4. SECTION Section_Identifier -Sections offered in a particular
semester must be different to avoid
the overlapping of the classes.
-This would affect the registration
process as also.
-It also depends on the year if the
course is newly added.
-It depends on the professor if he
wants to add an extra sction or not
based on the number students
enrolled.
5. GRADE_REPORT Student_number -Student number should be unique as
mentioned above even though they
& have same names.

Section_Identifier -Section Identified is a unique number


as stated above as it depends on the
semester, year the course is offered.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy