Data Models

Client/Server Architecture
• Front-end tier -> User Interface layer usually consisting of a mix of HTML,
Javascript, CSS, Flash, and various server-side code like ASP.Net, classic ASP, PHP,
etc. Think of this as being closest to the user in terms of code.

• Middleware, middle-tier -> One tier back, generally referred to as the

"plumbing" part of a system.

• Back-end tier -> Databases and other data stores are generally at this level.
Oracle, MS-SQL, MySQL, SAP, and various off-the-shelf pieces of software come
to mind for this piece of software that is the final processing of the data.
• 1-Tier, 2-Tier, 3-Tier,…. N-tier Architecture
Data Models
An integrated collection of concepts for describing and manipulating data,
relationships between data, and constraints on the data in an organization

A data models has three components

 Structural – with rules for building a db
 Manipulative – with rules for managing the data
 Integrity – with rules assuring data accuracy

The goal of the data model is to make sure that the all data objects
required by the database are completely and accurately
represented.
Disadvantages The hierarchical data model organizes data in a tree structure
• Implementation complexity 1:N mapping between record types
• Maintaining difficult
• Lack of structural independence
• programming complexity
Network Data Model
• The basic data modeling construct in the network model is the
set construct.
• A set consists of an owner record type, a set name, and a
member record type.

Sales Rep Customer

N ..1 N ..1 N ..1

Product Invoice Payment

N ..1 N ..1
Invoice line
Relational Data Model
• Relations are value oriented Data structures that is based
on the concept of mathematical relations
• The relational model consists of three components:
• A Structural component - a set of TABLES (also called
RELATIONS).
• A Manipulative component consisting of a set of high-level
operations which act upon and produce whole tables.
• A Set of Rules for maintaining the INTEGRITY of the database
• The terminology associated with relational database theory
originates from the branch of mathematics called set theory
• The most commonly used type of database is the relational
database
 Example Relation Instances
EMP WORKS
ENO PNO RESP PROJ
ENO ENAME TITLE DUR
E1 J. Doe Elect. Eng. E1 P1 Manager 12 PNO PNAME BUDGET
E2 M. Smith Syst. Anal. E2 P1 Analyst 24
E3 A. Lee Mech. Eng. P1 Instrumentation 150000
E2 P2 Analyst 6 P2 Database Develop. 135000
E4 J. Miller Programmer E3 P3 Consultant 10
P3 CAD/CAM 250000
E5 B. Casey Syst. Anal. E3 P4 Engineer 48 P4 Maintenance 310000
E6 L. Chu Elect. Eng. E4 P2 Programmer 18 P5 CAD/CAM 500000
E7 R. Davis Mech. Eng. E5 P2 Manager 24
E8 J. Jones Syst. Anal. E6 P4 Manager 48
E7 P3 Engineer 36
E7 P5 Engineer 23
E8 P3 Manager 40
Data in the form of table
each table - application entity
each row - instances of that entity
SQL serves as a uniform interface for users providing a collection of standard expression for storing and retrieving
data
Object Oriented Model
• Object-oriented database technology is a marriage of
object-oriented programming and database
technologies
Comparison of File, RDBMS, ORDBMS
and OODBMS

Query  RDBMS ORDBMS 

No Query File Sys.  OODBMS 

  Simple Data Complex Data

Hierarchical Network Relational Object Object
Relational Oriented
1. One to many or one 1. Support 1- M 1. 1-1 to ,1-M, M-N 1. OR= R+O 1. OO=
to one relationships. relationships. relationships OOP+DBM
2. Based on parent child 2. A record can have 2. Retrieve 2. DB Objects S
relationship. many parents as well algorithms 2. Objects
3. Does not provide an as many children. Simple 3. Object pro,
independent stand 3. CODASYL 3. Cod’s Rules (12) 3. Oracle 7.3, Orion,
alone query interface (Conference on Data 4. Relations Later versions ontos,
4. retrieval algorithms - Systems Languages) 5. SQL of RDBMS Jasmine
complex 4. Graph 6. Oracle 6.0,
5. Tree data Structure 5. Retrieve algorithms Sybase 10…
6. HDBMS complex
7. Example: IMS 6. DBTG
 Codd’s Rules
1. Information Rule 7. View update rule

2. Guaranteed Rule 8. Physical data Independence

3. Systematic treatment of null values 9. Logical data Independence

4. Self describing nature of the database 10. Distribution Independence

5. Comprehensive Data sun language rule 11. Integrity Independence

6. High level Insert/Update/delete rule 12. Non-subversion rule

Rule 1: Information rule
• All information(including metadata) is to be represented as stored
data in cells of tables.
• The rows and columns have to be strictly unordered.

PROJ

PNO PNAME BUDGET

P1 Instrumentation 150000
P2 Database Develop. 135000
P3 CAD/CAM 250000
P4 Maintenance 310000
P5 CAD/CAM 500000
Rule 2: Guaranteed Access
• Each unique piece of data(atomic value) should be accessible
by : Table Name + Primary Key(Row) + Attribute(column).
• NOTE: Ability to directly access via POINTER is a violation of this rule.
Rule 3: Systematic treatment of NULL
Values
• In a relational database, NULL values represent the missed and
inapplicable information in a systematic way. A NULL value is a special
value, which is neither zero nor empty string. All the database
systems support the NULL value concept.
Rule 4: Self describing nature of the
database
• This rule illustrates data dictionary.
• Metadata should be maintained for all the data in the database.
• These metadata should also be stored as tables, rows and columns.
• It should also have access privileges. In short, these metadata stored
in the data dictionary should also obey all the characteristics of a
database.
• Also, it should have correct up-to-date data.
• We should be able to access these metadata by using same query
language that we use to access the database.
• the relation names,
• attribute names,
• attribute domains (data types),
• descriptions of constraints (primary keys, secondary keys, foreign keys, NULL/ NOT NULL, and
other types of constraints),
• views, and storage structures and indexes (index name, attributes on which index is defined,
type of index etc).
• Security and authorisation information is also kept in the catalogue, which describes: •
• authorised user names and passwords,
• each user’s privilege to access specific database relations and views,
• the creator and owner of each relation.
• The privileges are granted using GRANT command.
• The system catalogue can also be used to store some statistical and descriptive information about relations.
• Some such information can be:
• number of tuples in each relation,
• the different attribute values,
• storage and access methods used in relation.
• All such information finds its use in query processing
Rule 5: Comprehensive Data Sub language
Rule
• DATABASE should always be accessed by using some strong query
language.
• This query language should be able to access the data, manipulate the
data and maintain the consistency and integrity of the database.
• They query should make sure that the transaction is fully complete or
not done at all.
Rule 6: View Update Rule

• Views are the virtual tables created by using queries to show the
partial view of the table. That is views are subset of table, it is only
partial table with few rows and columns. This rule states that views
are also be able to get updated as we do with its table.
Rule 7 High-level insert, update, and delete
• This rule states that every query language used by the database
should support INSERT, DELETE and UPDATE on the records.
• It should also support set operations like UNION, UNION ALL, MINUS,
INTERSECT and INTERSECT ALL.
• All these operation should not be restricted to single table or row at a
time.
• It should be able to handle multiple tables and rows in its operation.
Rule 8 Physical Data Independence
• If there is any change in the physical storage of the data, it should not
affect the data at the logical or external view.

• The physical storage of data should not matter to the system.

• If say, some file supporting table is renamed or moved from one disk
to another, it should not effect the application.
Rule 9 Logical Data Independence
• If there are any changes to the logical view, then it should not be
reflected in the user view.

• The logical data in a database must be independent of its user’s view

(application).
• Any change in logical data must not affect the applications using it.
• For example, if two tables are merged or one is split into two different
tables, there should be no impact or change on the user application.
This is one of the most difficult rule to apply.
Rule 10: Integrity Independence
• A database must be independent of the application that uses it.
• All its integrity constraints can be independently modified without the
need of any change in the application.
• This rule makes a database independent of the front-end application
and its interface.
Rule 11: Distribution Independence
• The end-user must not be able to see that the data is distributed over
various locations.
• Users should always get the impression that the data is located at one
site only.
• This rule has been regarded as the foundation of distributed database
systems.
Rule 12- Non-Subversion Rule
• If a system has an interface that provides access to low-level records,
then the interface must not be able to subvert the system and bypass
security and integrity constraints.
• You cannot violate the above said 11 rules even if your are
programmer who can directly code in Machine Language