1.

i. Database Design Strategies

Top-down strategy: We start with a schema containing high-level abstractions and then apply
successive top-down refinements. For example, we may specify only a few high-level entity
types and then, as we specify their attributes, split them into lower-level entity types and
relationships. The process of specialization to refine an entity type into subclasses.

Bottom-up strategy: Start with a schema containing basic abstractions and then combine or add
to these abstractions. For example, we may start with the attributes and group these into entity
types and relationships. We may add new relationships among entity types as the design
progresses. The process of generalizing entity types into higher-level generalized superclasses.

Inside-out strategy: This is a special case of a bottom-up strategy, where attention is focused on
a central set of concepts that are most evident. Modeling then spreads outward by considering
new concepts in the vicinity of existing ones. We could specify a few clearly evident entity types
in the schema and continue by adding other entity types and relationships that are related to each.

Mixed strategy: Instead of following any particular strategy throughout the design, the
requirements are partitioned according to a top-down strategy, and part of the schema is designed
for each partition according to a bottom-up strategy. The various schema parts are then
combined.

(Source: Elmasri & Navathe Book)

ii. Functional Dependence

A functional dependency is a constraint between two sets of attributes from the database. A
functional dependency occurs when one attribute in a relation uniquely determines another
attribute. This can be written A -> B which would be the same as stating "B is functionally
dependent upon A."
iii. Referential Integrity

The referential integrity constraint is specified between two relations and is used to maintain the
consistency among tuples in the two relations. Informally, the referential integrity constraint
states that a tuple in one relation that refers to another relation must refer to an existing tuple in
that relation.

To define referential integrity more formally, we first define the concept of a foreign key.

Example:

The attribute DNO of EMPLOYEE gives the department number for which each employee
works; hence, its value in every EMPLOYEE tuple must match the DNUMBER value of some
tuple in the DEPARTMENT relation.

iv. Entity Integrity

The entity integrity constraint states that no primary key value can be null. This is because the
primary key value is used to identify individual tuples in a relation. Having null values for the
primary key implies that we cannot identify some tuples.

For example, if two or more tuples had null for their primary keys, we might not be able to
distinguish them if we tried to reference them from other relations.

v. GIS

Geographic information systems (GIS) are used to collect, model, store, and analyze information
describing physical properties of the geographical world. The scope of GIS broadly encompasses
two types of data:
(1) spatial data, originating from maps, digital images, administrative and political boundaries,
roads, transportation networks; physical data such as rivers, soil characteristics, climatic regions,
land elevations
and
(2) non-spatial data, such as socio-economic data (like census counts), economic data, and sales
or marketing information.

GIS is a rapidly developing domain that offers highly innovative approaches to meet some
challenging technical demands.
vi.

The ultimate goal during normalization was to separate the logically related attributes into tables
to minimize redundancy, and thereby avoid the update anomalies that lead to an extra processing
overhead to maintain consistency in the database.

The above ideals are sometimes sacrificed in favor of faster execution of frequently occurring
queries and transactions. This process of storing the logical database design (which may be in
BCNF or 4NF) in a weaker normal form, say 2NF or 1NF, is called denormalization.

3.
a. DBA

- Administering Database, DBMS and related software is the responsibility of the database
administrator (DBA).
- The DBA is responsible for authorizing access to the database, for coordinating and monitoring
its use, and for acquiring software and hardware resources as needed.
- The DBA is accountable for problems such as breach of security or poor system response time.
- In large organizations, the DBA is assisted by a staff that helps carry out these functions.

Example > Employee <EmployeeID, NIC, Name, Address, EmpStatus, DepartmentID>

i. Super Key

A combination of attributes that can be uniquely used to identify a database record. A table
might have many super keys.

Ex: <EmployeeID>, <NIC>, <EmployeeID, NIC>, <EmployeeID, Name>, <EmployeeID, NIC,

Name, Address, EmpStatus, DepartmentID>

ii. Candidate Key

A relation schema may have more than one key. In this case, each of the keys is called a
candidate key. It is

Ex: EmployeeID, NIC

iii. Primary Key

The primary key of a relational table uniquely identifies each record in the table. It can either be
a normal attribute that is guaranteed to be unique (such as National Identity Card No in a table
with no more than one record per person) or it can be generated by the DBMS (such as a globally
unique identifier, or GUID, in Microsoft SQL Server). Primary keys may consist of a single
attribute or multiple attributes in combination.
Ex: EmployeeID

iv. Alternate Key

Can be named as 'Secondary key', is any Candidate key which is not selected as 'Primary Key'.

Ex: NIC

v. Foreign Key

A foreign key is a field in a relational table that matches the primary key column of another
table. The foreign key can be used to cross-reference tables. The referencing and referenced
table may be the same table. A table may have multiple foreign keys, and each foreign
key can have a different referenced table.

Ex: DepartmentID

4.
c.
i. SELECT Emp_ID
FROM WORKS
WHERE Company_ID = 'C003';

ii. SELECT l.Emp_ID, l.House_Number, l.Street, l.City

FROM WORKS w, LIVES l
WHERE w.Emp_ID = l.Emp_ID AND w.Company_ID = '0007' AND w.Salary < 40000;

iii. SELECT l.Emp_ID, l.City

FROM LIVES l, LOCATED_IN loc
WHERE l.City = loc.City;

iv. SELECT l.Emp_ID, l.HOuse_Number, l.Street, l.City

FROM LIVES l, MANAGER m
WHERE l.Emp_ID = m.Emp_ID AND m.MGR_ID = 'M002';

v. SELECT Emp_ID, Date_Joined

FROM WORKS
WHERE Company_ID = 'C012' AND Date_Joined BETWEEN '01-JAN-2009' AND '30-JAN-
2009';