Question 1: What do you mean by Data Model? What are its types? Explain.

Answer:

Data Model
A data model in software engineering is an abstract model that describes how data are
represented and accessed. Data models formally define data elements and relationships
among data elements for a domain of interest. According to Hoberman (2009), "A data
model is a wayfinding tool for both business and IT professionals, which uses a set of
symbols and text to precisely explain a subset of real information to improve
communication within the organization and thereby lead to a more flexible and stable
application environment."[2]

A data model explicitly determines the structure of data or structured data. Typical
applications of data models include database models, design of information systems, and
enabling exchange of data. Usually data models are specified in a data modeling
language.[3]

Communication and precision are the two key benefits that make a data model important
to applications that use and exchange data. A data model is the medium which project
team members from different backgrounds and with different levels of experience can
communicate with one another. Precision means that the terms and rules on a data model
can be interpreted only one way and are not ambiguous.[2]

A data model can be sometimes referred to as a data structure, especially in the context of
programming languages. Data models are often complemented by function models,
especially in the context of enterprise models.

Types of data models

Database model

A database model is a theory or specification describing how a database is structured and

used. Several such models have been suggested. Common models include:

• Flat model: This may not strictly qualify as a data model. The flat (or table) model
consists of a single, two-dimensional array of data elements, where all members
of a given column are assumed to be similar values, and all members of a row are
assumed to be related to one another.
• Hierarchical model: In this model data is organized into a tree-like structure,
implying a single upward link in each record to describe the nesting, and a sort
field to keep the records in a particular order in each same-level list.
 • Network model: This model organizes data using two fundamental constructs,
called records and sets. Records contain fields, and sets define one-to-many
relationships between records: one owner, many members.
• Relational model: is a database model based on first-order predicate logic. Its core
idea is to describe a database as a collection of predicates over a finite set of
predicate variables, describing constraints on the possible values and
combinations of values.

• Object-relational model: Similar to a relational database model, but objects,

classes and inheritance are directly supported in database schemas and in the
query language.
• Star schema is the simplest style of data warehouse schema. The star schema
consists of a few "fact tables" (possibly only one, justifying the name) referencing
any number of "dimension tables". The star schema is considered an important
special case of the snowflake schema.

Entity-relationship model

An entity-relationship model (ERM) is an abstract conceptual data model (or semantic

data model) used in software engineering to represent structured data. There are several
notations used for ERMs.

Geographic data model

A data model in Geographic information systems is a mathematical construct for

representing geographic objects or surfaces as data. For example,

• the vector data model represents geography as collections of points, lines, and
polygons;
• the raster data model represent geography as cell matrixes that store numeric
values;
• and the Triangulated irregular network (TIN) data model represents geography as
sets of contiguous, nonoverlapping triangles.[13]

Generic data model

Generic data models are generalizations of conventional data models. They define
standardised general relation types, together with the kinds of things that may be related
by such a relation type. Generic data models are developed as an approach to solve some
shortcomings of conventional data models. For example, different modelers usually
produce different conventional data models of the same domain. This can lead to
difficulty in bringing the models of different people together and is an obstacle for data
exchange and data integration. Invariably, however, this difference is attributable to
different levels of abstraction in the models and differences in the kinds of facts that can
be instantiated (the semantic expression capabilities of the models). The modelers need to
communicate and agree on certain elements which are to be rendered more concretely, in
order to make the differences less significant.

Semantic data model

A semantic data model in software engineering is a technique to define the meaning of

data within the context of its interrelationships with other data. A semantic data model is
an abstraction which defines how the stored symbols relate to the real world.[12] A
semantic data model is sometimes called a conceptual data model.

The logical data structure of a database management system (DBMS), whether

hierarchical, network, or relational, cannot totally satisfy the requirements for a
conceptual definition of data because it is limited in scope and biased toward the
implementation strategy employed by the DBMS. Therefore, the need to define data from
a conceptual view has led to the development of semantic data modeling techniques. That
is, techniques to define the meaning of data within the context of its interrelationships
with other data. As illustrated in the figure. The real world, in terms of resources, ideas,
events, etc., are symbolically defined within physical data stores. A semantic data model
is an abstraction which defines how the stored symbols relate to the real world. Thus, the
model must be a true representation of the real world.[12]

Question 2: What is functional dependency? Who specifiles the functional dependencies

that hold among the attributes of a relational schema?

Functional dependency
A functional dependency (FD) is a constraint between two sets of attributes in a relation
from a database.

Given a relation R, a set of attributes X in R is said to functionally determine another

attribute Y, also in R, (written X → Y) if and only if each X value is associated with
precisely one Y value. Customarily we call X the determinant set and Y the dependent
attribute. Thus, given a tuple and the values of the attributes in X, one can determine the
corresponding value of the Y attribute. For the purposes of simplicity, given that X and Y
are sets of attributes in R, X → Y denotes that X functionally determines each of the
members of Y - in this case Y is known as the dependent set. Thus, a candidate key is a
minimal set of attributes that functionally determine all of the attributes in a relation.

A functional dependency FD: X → Y is called trivial if Y is a subset of X.

The determination of functional dependencies is an important part of designing databases

in the relational model, and in database normalization and denormalization. The
functional dependencies, along with the attribute domains, are selected so as to generate
constraints that would exclude as much data inappropriate to the user domain from the
system as possible.
For example, suppose one is designing a system to track vehicles and the capacity of their
engines. Each vehicle has a unique vehicle identification number (VIN). One would write
VIN → EngineCapacity because it would be inappropriate for a vehicle's engine to have
more than one capacity. (Assuming, in this case, that vehicles only have one engine.)
However, EngineCapacity → VIN, is incorrect because there could be many vehicles
with the same engine capacity.

This functional dependency may suggest that the attribute EngineCapacity be placed in a
relation with candidate key VIN. However, that may not always be appropriate. For
example, if that functional dependency occurs as a result of the transitive functional
dependencies VIN → VehicleModel and VehicleModel → EngineCapacity then that
would not result in a normalized relation.

Irreducible function depending set

A functional depending set S is irreducible if the set has following three properties:

1. Each right set of a functional dependency of S contains only one attribute.

2. Each left set of a functional dependency of S is irreducible. It means that reducing
any one attribute from left set will change the content of S (S will lose some
information).
3. Reducing any functional dependency will change the content of S.

Sets of Functional Dependencies(FD) with these properties are also called canonical or
minimal.

Properties of functional dependencies

Given that X, Y, and Z are sets of attributes in a relation R, one can derive several
properties of functional dependencies. Among the most important are Armstrong's
axioms, which are used in database normalization:

• Subset Property (Axiom of Reflexivity): If Y is a subset of X, then X → Y

• Augmentation (Axiom of Augmentation): If X → Y, then XZ → YZ
• Transitivity (Axiom of Transitivity): If X → Y and Y → Z, then X → Z

From these rules, we can derive these secondary rules:

• Union: If X → Y and X → Z, then X → YZ

• Decomposition: If X → YZ, then X → Y and X → Z
• Pseudotransitivity: If X → Y and WY → Z, then WX → Z

Equivalent sets of functional dependencies are called covers of each other. Every set of
functional dependencies has a canonical cover.
Example
This example illustrates the concept of functional dependency. The situation modeled is
that of college students visiting one or more lectures in each of which they are assigned a
teaching assistant (TA). Let's further assume that every student is in some semester and is
identified by an unique integer ID.

StudentID Semester Lecture TA

1234 6 Numerical Methods John
1201 4 Numerical Methods Peter
1234 6 Visual Computing Amin
1201 4 Numerical Methods Peter
1201 4 Physics II Simone

We notice that whenever two rows in this table feature the same StudentID, they also
necessarily have the same Semester values. This basic fact can be expressed by a
functional dependency:

• StudentID → Semester.

Other nontrivial functional dependencies can be identified, for example:

• {StudentID, Lecture} → TA
• {StudentID, Lecture} → {TA, Semester}

The latter expresses the fact that the set {StudentID, Lecture} is a superkey of the
relation.

Question 3: Describe various ways of creating a table in Access?

Answer:

How to create a table in an Access database

View products that this article applies to.
This article was previously published under Q304238
Novice: Requires knowledge of the user interface on single-user computers.

This article applies to a Microsoft Access database (.mdb) and to a Microsoft Access
project (.adp).

For a Microsoft Access 2000 version of this article, see 304262

(http://support.microsoft.com/kb/304262/EN-US/ ) .
For a Microsoft Access97 version of this article, see 304450
(http://support.microsoft.com/kb/304450/ ) .
Expand all | Collapse all
SUMMARY
In the Microsoft Access user interface, you can create a
table in a database by...
In the Microsoft Access user interface, you can create a table in a database by using
any of the follow three methods:

• You can create a table by using the Table Wizard.

• You can create a table by entering data into a datasheet.
• You can create a table in Design View.

This article shows you how to use each of these methods.

MORE INFORMATION
Creating a Table by Using the Table Wizard Microsoft
Access has a wizard named...
Creating a Table by Using the Table Wizard
Microsoft Access has a wizard named the Table Wizard that will create a table for
you. This wizard gives you suggestions about what type of table you can create (for
example, a Mailing List table, a Students table, a Tasks table, and so on) and gives you
many different possible names for fields within these tables. To use the Table Wizard to
create a table, follow these steps:

1. Create a new, blank database.

2. In the Database window, click Tables under Objects, and then click New.
3. In the New Table dialog box, double-click Table Wizard.
4. Follow the directions in the Table Wizard pages.

If you want to modify the table that the Table Wizard creates, open the table in Design
view when you have finished using the Table Wizard.

Creating a Table by Entering Data in a Datasheet

In Microsoft Access, you can also create a table by just entering data into columns
(fields) in a datasheet. If you enter data that is consistent in each column (for example,
only names in one column, or only numbers in another column), Access will
automatically assign a data type to the fields. To create a table by just entering data in a
datasheet, follow these steps:

1. Create a new, blank database.

2. In the Database window, click Tables under Objects, and then click New.
3. In the New Table dialog box, double-click Datasheet View. A blank datasheet is
displayed with default column names Field1, Field2, and so on.
4. Rename each column that you want to use. To do so, double-click the column
name, type a name for the column, and then press ENTER.

You can insert additional columns at any time. To do so, click in the column to
the right of where you want to insert a new column, and then on the Insert menu,
click Column. Rename the column as described earlier.
5. Enter your data in the datasheet. Enter each kind of data in its own column. For
example, if you are entering names, enter the first name in its own column and the
last name in a separate column. If you are entering dates, times, or numbers, enter
them in a consistent format. If you enter data in a consistent manner, Microsoft
Access can create an appropriate data type and display format for the column. For
example, for a column in which you enter only names, Access will assign the Text
data type; for a column in which you enter only numbers, Access will assign a
Number data type. Any columns that you leave empty will be deleted when you
save the datasheet.
6. When you have added data to all the columns that you want to use, click Save on
the File menu.
7. Microsoft Access asks you if you want to create a primary key. If you have not
entered data that can be used to uniquely identify each row in your table, such as
part numbers or an ID numbers, it is recommended that you click Yes. If you have
entered data that can uniquely identify each row, click No, and then specify the
field that contains that data as your primary key in Design view after the table has
been saved. To define a field as your primary key after the table has been saved,
follow these steps:

a. Open the table that Access created from the data that you entered in
datasheet in Design view.
b. Select the field or fields that you want to define as the primary key.

To select one field, click the row selector for the desired field.

To select multiple fields, hold down the CTRL key, and then click the row
selector for each field.
c. On the Edit menu, click Primary Key.

If you want the order of the fields in a multiple-field primary key to be

different from the order of those fields in the table, click Indexes on the
toolbar to display the Indexes window, and then reorder the field names
for the index named PrimaryKey.

As mentioned earlier, Microsoft Access will assign data types to each field
(column) based on the kind of data that you entered. If you want to customize a
field's definition further--for example, to change a data type that Access
 automatically assigned, or to define a validation rule--open the table in Design
view.

Creating a Table in Design View

If you want to create the basic table structure yourself and define all the field names
and data types, you can create the table in Design view. To do so, follow these steps:

1. Create a new, blank database.

2. In the Database window, click Tables under Objects, and then click New.
3. In the New Table dialog box, double-click Design View.
4. In the <Table Name>: Table dialog box, define each of the fields that you want
to include in your table. To do so, follow these steps:

a. Click in the Field Name column, and then type a unique name for the
field.
b. In the Data Type column, accept the default data type of Text that Access
assigns or click in the Data Type column, click the arrow, and then select
the data type that you want.
c. In the Description column, type a description of the information that this
field will contain. This description is displayed on the status bar when you
are adding data to the field, and it is included in the Object Definition of
the table. The description is optional.
d. Once you have added some fields, you may need to insert a field between
two other fields. To do so, click in the row below where you want to add
the new field, and then on the Insert menu, click Rows. This creates a
blank row in which you can add a new field.

To add a field to the end of the table, click in the first blank row.
2. After you have added all the fields, define a primary key field before saving your
table. A primary key is one or more fields whose value or values uniquely identify
each record in a table. To define a primary key, follow these steps:

a. Select the field or fields that you want to define as the primary key.

To select one field, click the row selector for the desired field.

To select multiple fields, hold down the CTRL key, and then click the row
selector for each field.
b. On the Edit menu, click Primary Key.
2. If you want the order of the fields in a multiple-field primary key to be different
from the order of those fields in the table, click Indexes on the toolbar to display
the Indexes dialog box, and then reorder the field names for the index named
PrimaryKey.

You do not have to define a primary key, but it is usually a good idea. If you do
 not define a primary key, Microsoft Access asks if you want Access to create one
for you when you save the table.
3. When you are ready to save your table, on the File menu, click Save, and then
type a unique name for the table.
What do you understand by DML?

Answer: Data Manipulation Language (DML) is a family of computer languages used

by computer programs and/or database users to insert, delete and update data in a
database. Read-only querying, i.e. SELECT, of this data may be considered to be either
part of DML or outside it, depending on the context.

Currently the most popular data manipulation language is that of SQL, which is used to
retrieve and manipulate data in a Relational database.[1] Other forms of DML are those
used by IMS/DLI, CODASYL databases (such as IDMS), and others.

Data Manipulation Language comprises the 'SQL-data change' statements[2], which

modify stored data but not the schema or database objects. Manipulation of persistent
database objects (e.g. tables or stored procedures) via the 'SQL-schema' statements[2],
rather than the data stored within them, is considered to be part of a separate Data
Definition Language. In SQL these two categories are similar in their detailed syntax,
data types, expressions etc., but distinct in their overall function.[2]

Data Manipulation Languages have their functional capability organized by the initial
word in a statement, which is almost always a verb. In the case of SQL, these verbs are:

• SELECT ... FROM ... WHERE ...

• INSERT INTO ... VALUES ...
• UPDATE ... SET ... WHERE ...
• DELETE FROM ... WHERE ...

The purely read-only SELECT query statement is classed with the 'SQL-data' statements[2]
and so is considered by the standard to be outside of DML. The SELECT ... INTO form
is considered to be DML because it manipulates (i.e. modifies) data. In common practice
though, this distinction is not made and SELECT is widely considered to be part of DML.[3]

Most SQL database implementations extend their SQL capabilities by providing

imperative, i.e., procedural, languages. Examples of these are Oracle's PL/SQL and
DB2's SQL PL.

Data manipulation languages tend to have many different flavors and capabilities
between database vendors. There have been a number of standards established for SQL
by ANSI,[1] but vendors still provide their own extensions to the standard while not
implementing the entire standard.

There are two types of data manipulation languages:

• Procedural
• Declarative
Each SQL DML statement is a declarative command. The individual SQL statements are
declarative, as opposed to imperative, in that they describe what the program should
accomplish, rather than describing how to go about accomplishing it.

Data manipulation languages were initially only used by computer programs, but (with
the advent of SQL) have come to be used by people as well.

SUMMARY
• Data Manipulation Language Commands allow manipulation of
data in the database tables
• The SELECT command is used to retrieve information from the
database tables
• The SELECT command is one of the most important commands
in the SQL language
• A new row can be added to a table by means of the INSERT
command
• Multiple rows of data cannot be added with a single INSERT
statement unless a SELECT statement replaces the VALUES
clause
• Existing rows in a table can be modified using the UPDATE
command
• The DELETE command is used to remove existing rows from a
Table