0% found this document useful (0 votes)
225 views

Module 1 - Database Concepts and Architecture

Uploaded by

v help
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
225 views

Module 1 - Database Concepts and Architecture

Uploaded by

v help
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 94

CSE2004: Database Management System

Module 1
Database Concepts and
Architecture
History and motivation for database systems –characteristics of database approach – Actors on
the scene – Workers behind the scene – Advantages of using DBMS approach, Data Models,
Schemas, and Instances, Three Schema Architecture and Data Independence, The Database
System Environment, Centralized and Client/Server Architectures for DBMSs, Classification of

database management systems .


Slide 1- 2

Staff Name: Dr.Sivabalakrishnan.M


Cabin : NO 26 (4th Floor Annex)
Email: [email protected]
Phone: 9841260016

TEXT BOOKS
R. Elmasri & S. B. Navathe, Fundamentals of Database Systems, Addison Wesley, 7th Edition, 2015
Raghu Ramakrishnan,Database Management Systems,Mcgraw-Hill,4th edition,2015

REFERENCES
A. Silberschatz, H. F. Korth & S. Sudershan, Database System Concepts, McGraw Hill, 6th Edition 2010
Thomas Connolly, Carolyn Begg,‖ Database Systems : A Practical Approach to Design, Implementation and
Management‖,6th Edition,2012
Pramod J. Sadalage and Marin Fowler, NoSQL Distilled: A brief guide to merging world of Polyglot
persistence, Addison Wesley, 2012.
Shashank Tiwari ,―Professional NoSql‖,Wiley ,2011
Topics to be Covered

 Introduction (Data, Database, DBMS)


 DBMS Functionalities
 Characteristics of DBMS Approach
 Database Users
 Advantages of DBMS
 DBMS History
 Extending Capabilities
Data

 It is a raw material or fact


 Example
 Registration Number / Name

Dr. M. Premalatha, VIT Chennai


Information
 A data has some meaning
 Knowledge, intelligence, a particular piece of data with a special
meaning or function. Information is often the result of combining,
comparing, and performing calculations on data

Dr. M. Premalatha, VIT Chennai


Database

 It is a collection of
interrelated data
 Example:
 Department
 Courses
 Grades

Dr. M. Premalatha, VIT Chennai


Database

 Database is an organized collection of


data, generally stored and accessed
electronically from a computer system

 It is controlled by Database
Management System

Dr. M. Premalatha, VIT Chennai


Database

 Modeled in rows and columns in a


series of tables

 The data can be accessed / arranged


/ managed / modified / organized

www.oracle.com
Dr. M. Premalatha, VIT Chennai
Properties of database

 Database represent some aspect of real world


 Database is logically coherent collection of data with some
inherent meaning
 Database is designed, build with data for specific purpose.
 Database can be any size and complexity.
 Database may be generated and maintained manually or it may
be computerized

Dr. M. Premalatha, VIT Chennai


Database - Example

Fundamentals Database Systems, Elmasri, Navathe, 7th Edition, Pearson Publication


Dr. M. Premalatha, VIT Chennai
Database Management System (DBMS)
 A Database Management System is
software designed to store /
retrieve / define and manage in a
Database
 Examples: MS-Access / MySQL /
SQL Server / Oracle / RDBMS etc.,

www.oracle.com
Database System

Fundamentals of Database Systems, Elmasri, Navathe, 7 th Edition, Pearson Publication


DBMS

Dr. M. Premalatha, VIT Chennai


DBMS Functionalities

 Define a particular database in terms


of its data types, structures, and
constraints
 Construct or Load the initial database
contents on a secondary storage
medium

www.oracle.com
DBMS Functionalities

 Manipulating the database:


 Retrieval: Querying, generating
reports
 Modification: Insertions, deletions
and updates to its content
 Accessing the database through Web
applications
www.oracle.com
Dr. M. Premalatha, VIT Chennai
DBMS Functionalities

 Protection or Security measures to


prevent unauthorized access
 Presentation and Visualization of Data
 Maintaining the Database and
associated Programs over the life time
of Database Application

www.oracle.com
Dr. M. Premalatha, VIT Chennai
Characteristics of Database Approach

1. Self-describing nature of a
database system
 A catalog stores the description of
a particular DB (Data structures /
types / constraints) : Meta-data
 Allows DBMS to work with
different DB applications
Characteristics of Database Approach

2. Insulation between programs and data


 Called program-data independence.
 Allows changing data structures and
storage organization without having to
change the DBMS access programs.
Characteristics of Database Approach

3. Data Abstraction

 A data model is used to hide storage


details and present the users with a
conceptual view of the database.
Characteristics of Database Approach

4. Support of multiple views of the data

 Each user may see a different view of


the database, which describes only the
data of interest to that user.
Characteristics of Database Approach
5. Sharing of data and multi-user
transaction processing
 A set of concurrent users to
retrieve from and to update the
database.

 Concurrency control: each


transaction is correctly
executed or aborted
Characteristics of Database Approach
5. Sharing of data and multi-user
transaction processing
 Recovery: each completed
transaction has its effect
permanently recorded in the
database
 OLTP (Online Transaction
Processing) : allows hundreds of
concurrent transactions to
execute per second.
Database - Example

Catalog View
Fundamentals Database Systems, Elmasri, Navathe, 7 th Edition, Pearson Publication
Database Users
 Actors on the Screen
 Use & Control the DB
 Design, Develop and Maintain DB Applications

 Workers behind the Screen


 Design and Develop DBMS Software and
related Tools (Computer System Operators)
Actors on the Screen
1. Database Administrators (DBA)

 Responsible for authorizing access


to the database
 For coordinating and monitoring its
use
 Acquiring software and hardware
resources
Actors on the Screen
2. Database Designers

 Responsible to define
 the content,
 the structure,
 the constraints and
 functions or transactions

 They must communicate with the end-users and


understand their needs.
Actors on the Screen
3. End Users

 Use the data for queries, reports and some of them update the
database content.

 Categorized in to:
Casual: access database (when needed)

Naïve or Parametric: they make up a large section of the end-


user population.

 Examples: Bank-tellers or reservation clerks (Do the same


for Entire Shift)
Actors on the Screen

 Sophisticated
 Business analysts, scientists, engineers

 Stand-alone
 Personal Databases (Tax / Address Book)
File processing system
A file system is a process that
manages how and where data on a
storage disk, typically a hard disk
drive (HDD), is stored, accessed
and managed.

Dr. M. Premalatha, VIT Chennai


Disadvantage of File-oriented system:
1. Data Redundancy:
 It is possible that the same information may be duplicated in different files.this leads to data redundancy
results in memory wastage.
2. Data Inconsistency:
 Because of data redundancy,it is possible that data may not be in consistent state.
3. Difficulty in Accessing Data:
 Accessing data is not convenient and efficient in file processing system.
4. Limited Data Sharing:
 Data are scattered in various files.also different files may have different formats and these files may be stored
in different folders may be of different departments.
 So, due to this data isolation, it is difficult to share data among different applications.
5. Integrity Problems:
 Data integrity means that the data contained in the database in both correct and consistent.for this purpose
the data stored in database must satisfy correct and constraints.
6. Atomicity Problems:
 Any operation on database must be atomic.
 this means, it must happen in its entirely or not at all.
7. Concurrent Access Anomalies:
 Multiple users are allowed to access data simultaneously.t his is for the sake of better performance and faster
response.
8. Security Problems:
 Database should be accessible to users in limited way.
 Each user should be allowed to access data concerning his requirements only. Dr. M. Premalatha, VIT Chennai
Advantages of Using the DBMS Approach
 Controlling Redundancy
 Restricting Unauthorized Access
 Providing Persistent Storage for
Program Objects
 Providing Storage Structures and
Search Techniques for Efficient
Query Processing
 Providing Backup and Recovery
Advantages of Using the DBMS Approach

 Providing Multiple User Interfaces


 Representing Complex Relationships
among Data
 Enforcing Integrity Constraints
 Permitting Inferencing and Actions
Using Rules and Triggers
Advantages of Using the DBMS Approach
 Additional Implications of Using the
Database Approach
 Potential for Enforcing Standards
 Reduced Application Development
Time
 Flexibility
 Availability of Up-to-Date Information
 Economies of Scale
Data Models

 Data Model: A set of

 Components of requirements
 Structure of DB
 Planning of DB
 Helps us to put real world
requirements to a design

Image Source: https://powerpivotpro.com/2016/02/data-modeling-power-pivot-power-bi/


Data Model - Categories
 Conceptual (high-level, semantic) data models:
 Provide concepts that are close to the way
many users perceive data.
 (Also called entity-based or object-based
data models.)
 Physical (low-level, internal) data models:
 Provide concepts that describe details of how
data is stored in the computer.
 Implementation (representational) data models:
 Provide concepts that fall between the above
two, used by many commercial DBMS
implementations.
Data Models

Types:
 Object based(data at user and Application level),
 Physical based(how data stored in memory, each tables are built and
related),
 Record based(data at user and Application level)
Three types:
 Hierarchical(parent-child relationship drawback :duplication)
 Relational(developed for long storage of data, large scale
application,uses of relation of set theory. information stored
in tables-attributes and tuples)
 Network data model(drawback of hierarchical model is
overcome)

Image Source: https://powerpivotpro.com/2016/02/data-modeling-power-pivot-power-bi/


Schema vs Instances
 Database Schema:
 The description of a database.
 Includes descriptions of the database
structure, data types, and the constraints on
the database.
 Schema Diagram:
 An illustrative display of (most aspects of) a
database schema.
 Schema Construct:
 A component of the schema or an object
within the schema, e.g., STUDENT, COURSE.
Schema vs Instances

 Database State:
 The actual data stored in a database at a
particular moment in time. This includes
the collection of all the data in the
database.
 Also called database instance (or
occurrence or snapshot).
 The term instance is also applied to
individual database components, e.g. record
instance, table instance, entity instance.
Database Schema vs State
 Database State:
 Refers to the content of a database at a
moment in time.
 Initial Database State:
 Refers to the database state when it is
initially loaded into the system.
 Valid State:
 A state that satisfies the structure and
constraints of the database.
Database Schema vs State
 Distinction
 The database schema changes very
infrequently.
 The database state changes every time
the database is updated.

 Schema is also called intension.


 State is also called extension.
Database Schema - Example

Image Source: Ramez Elmasri and Shamkant B. Navathe


Database State - Example

Image Source: Ramez Elmasri and Shamkant B. Navathe


Three-Schema Architecture
 Proposed to support DBMS characteristics of:
 Program-data independence.
 Support of multiple views of the data.

 Not explicitly used in commercial DBMS products, but has been useful in
explaining database system organization
Three-Schema Architecture
 Defines DBMS schemas at three levels:
 Internal schema at the internal level to describe physical
storage structures and access paths (e.g indexes).
 Typically uses a physical data model.
 Conceptual schema at the conceptual level to describe the
structure and constraints for the whole database for a
community of users.
 Uses a conceptual or an implementation data model.
 External schemas at the external level to describe the various
user views.
 Usually uses the same data model as the conceptual schema.
 The conceptual level supports each external view, in that any data available to a user must be contained in, or
derivable from, the conceptual level. However, this level must not contain any storage dependent details. For
instance, the description of an entity should contain only data types of attributes (for example, integer, real,
character) and their length (such as the maximum number of digits or characters), but not any strange
considerations, such as the number of bytes occupied. Conceptual level is also known as the, logical level.
 The internal level is concerned with such things as:
• Storage space allocation for data and indexes;
• Record descriptions for storage (with stored sizes for data items);
• Record placement;
• Data compression and data encryption techniques.
 There will be only one conceptual view, consisting of the abstract representation
of the database in it’s entirely. Similarly there will be only one internal or physical
view, representing the total database, as it is physically stored.

Dr. M. Premalatha, VIT Chennai


Slide 2- 47

The three-schema architecture


Three-Schema Architecture
 Mappings among schema levels are needed to transform requests and
data.
 Programs refer to an external schema, and are mapped by the DBMS to
the internal schema for execution.
 Data extracted from the internal DBMS level is reformatted to match
the user’s external view (e.g. formatting the results of an SQL query for
display in a Web page)
Example

Dr. M. Premalatha, VIT Chennai


Data Independence
 Logical Data Independence:
 The capacity to change the conceptual schema without having to change the
external schemas and their associated application programs.

 Physical Data Independence:


 The capacity to change the internal schema without having to change the
conceptual schema.
 For example, the internal schema may be changed when certain file structures
are reorganized or new indexes are created to improve database performance
Data Independence (continued)
 When a schema at a lower level is changed, only the mappings between
this schema and higher-level schemas need to be changed in a DBMS that
fully supports data independence.
 The higher-level schemas themselves are unchanged.
 Hence, the application programs need not be changed since they refer
to the external schemas.
DBMS Architecture

 DBMS design depends upon its architecture.


 Client/server architecture is used to deal with a
large number of PCs, web servers, database
servers and other components that are
connected with networks.
 Client/server architecture consists of many PCs
and a workstation which are connected via the
network.
1- Tier Architecture

 In this architecture, the database is directly


accessed by the user.
 Any changes will be performed over the database
itself.
 Used for development of the local application,
where programmers can directly communicate
with the database for the quick response.

Image Source: guru99.com


2 - Tier Architecture

 It is basic client-server. But Applications on the client end can


directly communicate with the database at the server side.
 For this interaction, API’s like: ODBC, JDBC are used. The user
interfaces and application programs are run on the client-side.
 The server side is responsible to provide the functionalities
like: query processing and transaction management.
 To communicate with the DBMS, client-side application
establishes a connection with the server side.

Image Source: guru99.com


3 - Tier Architecture

 The 3-Tier architecture contains another layer between the client and
server.
 In this architecture, client can’t directly communicate with the server.
 The application on the client-end interacts with an application server
which further communicates with the database system.
 End user has no idea about the existence of the database beyond the
application server and the database also has no idea about any other
user beyond the application.
 The 3-Tier architecture is used in case of large web application.

Image Source: guru99.com


3 - Tier Architecture
The 3-tier architecture consists of the following layers:
Presentation layer: This layer is also known as the client layer. It is the front end layer in the 3-
tier architecture and consists of a user interface. The main purpose of this layer is to
communicate with the application layer.
Application layer: This layer is also known as the business logic layer. It acts as a middle layer
between the client and the database server for exchange of partially processed data.
Database layer: The data or information is stored in this layer. This layer contains a method to
connect with the database and to perform operations such as insert, update, and delete .

The goal of three-tier architecture is to:


• Support multiple views of data
• Help in programming data independence
• Propose to support DBMS architecture
• It separates the user applications from the physical database
Dr. M. Premalatha, VIT Chennai
Comparing 2 - Tier & 3 - Tier
Architecture
History of Data Models
 Relational Model: proposed in 1970 by E.F. Codd (IBM), first
commercial system in 1981-82.
 Eg.(DB2, ORACLE, SQL Server, SYBASE, INFORMIX).
 Network Model: the first one to be implemented by Honeywell in
1964-65 (IDS System). Adopted heavily due to the support by CODASYL
(CODASYL - DBTG report of 1971). Later implemented in a large variety
of systems - IDMS (Cullinet - now CA), DMS 1100 (Unisys), IMAGE (H.P.),
VAX -DBMS (Digital Equipment Corp.).
 Hierarchical Data Model: implemented in a joint effort by IBM and
North American Rockwell around 1965. Resulted in the IMS family of
systems. The most popular model. Other system based on this model:
System 2k (SAS inc.)
History of Data Models
 Object-oriented Data Model(s):
 Several models have been proposed for implementing in a
database system. One set comprises models of persistent O-O
Programming Languages such as C++ (e.g., in OBJECTSTORE or
VERSANT), and Smalltalk (e.g., in GEMSTONE).
 Additionally, systems like O 2, ORION (at MCC - then ITASCA),
IRIS (at H.P.- used in Open OODB).
 Object-Relational Models:
 Most Recent Trend. Started with Informix Universal Server.
Exemplified in the latest versions of Oracle-10i, DB2, and SQL
Server etc. systems.
Hierarchical Data Model

 In Hierarchical Model, a hierarchical relation is formed


by collection of relations and forms a tree-like
structure.
 The relationship can be defined in the form of parent
child type.
 One of the first and most popular Hierarchical Model is
Information Management System (IMS), developed by
IBM.
Hierarchical

Data Model - Merits and Demerits
Merits
 The design of the hierarchical model is simple.
 Provides Data Integrity since it is based on parent/ child relationship
 Data sharing is feasible since the data is stored in a single database.
 Even for large volumes of data, this model works perfectly.
 De-Merits
 Implementation is complex.
 This model has to deal with anomalies like Insert, Update and
Delete.
 Maintenance is difficult since changes done in the database may
want you to do changes in the entire database structure.
Network Data Model

 The Hierarchical Model creates hierarchical tree with parent/ child


relationship, whereas the Network Model has graph and links.
 The relationship can be defined in the form of links and it handles
many-to-many relations. This itself states that a record can have
more than one parent.
Network Data Model - Merits and Demerits
 Merits
 Easy to design the Network Model
 The model can handle one-one, one-to-many, many-to-many
relationships.
 It isolates the program from other details.
 Based on standards and conventions.
 De-Merits
 Pointers bring complexity since the records are based on pointers
and graphs.
 Changes in the database isn’t easy that makes it hard to achieve
structural independence.
Relational Data Model

 A Relational model groups data into one or more tables. These


tables are related to each other using common records.
 The data is represented in the form of rows and columns i.e.
tables.
Relational Data Model

 Example : Let us see an example of two relations <Employee> and


<Department> linked to each other, with DepartmentID, which is
Foreign Key of <Employee> table and Primary key of
<Department> table.
Relational Data Model - Merits and Demerits
 Merits
 It does not have any issues that we saw in the
previous two models i.e. update, insert and delete
anomalies have nothing to do in this model.
 Changes in the database do not require you to affect
the complete database.
 Implementation of a Relational Model is easy.
 To maintain a Relational Model is not a tiresome
task.
 De-Merits
 Database inefficiencies hide and arise when the
model has large volumes of data.
 The overheads of using relational data model come
with the cost of using powerful hardware and
devices.
DBMS Interfaces
 Stand-alone query language interfaces.
 Programmer interfaces for embedding DML in programming languages:
 Pre-compiler Approach.
 Procedure (Subroutine) Call Approach.
 User-friendly interfaces:
 Menu-based, popular for browsing on the web
 Forms-based, designed for users.
 Graphics-based (Point and Click, Drag and Drop etc.).
 Natural language: requests in written English.
 Combinations of the above.
 Interfaces for the DBA:
 Creating accounts, granting authorizations.
 Setting system parameters.
 Changing schema’s or access path.
Centralized Database Management System

 A centralized database is stored at a single location such as a


mainframe computer.
 It is maintained and modified from that location only and
usually accessed using an internet connection such as a LAN or
WAN.
 The centralized database is used by organizations such as
colleges, companies, banks etc.
Merits and De-merits of Centralized DBMS
 Advantages :
 The Data Integrity is maximized as the whole database is stored at a single physical
location. It is easier to coordinate the data and it is as accurate and consistent as
possible.
 The Data Redundancy is minimal in the centralized database. All the data is stored
together and not scattered across different locations. So, there is no redundant data
available.
 Since all the data is in one place, there can be stronger security measures around it.
So, It is much more secure.
 Data is easily portable because it is stored at the same place.
 It is cheaper than other types of databases as it requires less power and maintenance.
 All the information can be easily accessed from the same location and at the same
time.
Merits and De-merits of Centralized DBMS
 Disadvantages :
 Since all the data is at one location, it takes more time to search and
access it. If the network is slow, this process takes even more time.
 There is a lot of data access traffic for the centralized database. This
may create a bottleneck situation.
 Since all the data is at the same location, if multiple users try to
access it simultaneously it creates a problem. This may reduce the
efficiency
 of the system.
 If there are no database recovery measures in place and a system
failure occurs, then all the data in the database will be destroyed.
Applications of Centralized System
 Application development – Very easy to setup a central server and send client
requests. Modern technology these days do come with default test servers which can
be launched with a couple commands. For example, express server, django server.
 Data analysis – Easy to do data analysis when all the data is in one place and available
for analysis
 Personal computing
Use Cases –
 Centralized databases – all the data in one server for use.
 Single player games like Need For Speed, GTA Vice City – entire game in one
system(commonly, a Personal Computer)
 Application development by deploying test servers leading to easy debugging, easy
deployment, easy simulation
 Personal Computers

Dr. M. Premalatha, VIT Chennai


Why do we Need a Centralized Database?

 An organization may have several business processes running for various


departments simultaneously. This may create issues if the organization
wants to check on the data daily and the centralized database comes in
handy in such cases.
 centralized database not only helps in getting the information quicker with
more ease but also helps in taking the business decisions as well. The
usage of the Centralised Database ensures the security of the data, ease of
accessing data from one place as well as providing a complete view of the
data effectively reducing the extra layer of information.

Dr. M. Premalatha, VIT Chennai


Client-Server Database Management System

 A client does not share any of its resources, but requests a


server’s content or service function.
 Clients therefore initiate communication sessions with servers
which await incoming requests.
 Examples of computer applications that use the client–server
model are Email, network printing, and the World Wide Web.

Image Source: guru99.com


Merits and De-merits of Client-Server DDBMS
 Advantages :
 Centralization – Access, Resources, and Data Security
are controlled through server.
 Scalability – Any element can be upgraded when
needed.
 Flexibiltiy – New Technology can be easily integrated
into the system.
 Interoperabilty – All components work together.
Merits and De-merits of Client-Server DDBMS
 Disadvantages :
 Dependability – When Servers goes down, operations
will cease.
 Lack of Mature Tools - To administrate.
 Lack of Scalability – Network OS are not vary scalable.
 Higher than anticipated Cost.
 Network Congestion.
DBMS History
 Early Database Applications
Hierarchical and Network Models (1960-70).
 Relational Model based Systems:
 Experimented within IBM Research (1970)
and several universities.
 Relational DBMS Products (1980s).
DBMS History
 Object Oriented and Emerging Applications
 Object Oriented DBMS (OODBMS)
 Object Oriented Relational DBMS (OORDBMS)
 Data on Web and E-Commerce Applications
 Hyper Text Markup Language (HTML)
 eXtended Markup Language (XML)
 Java Script / PHP Programming Languages
Extending DBMS Capabilities
 Scientific Applications
 XML (eXtensible Markup Language)
 Image Storage and Management
 Audio and Video Data Management
 Data Warehousing and Data Mining
 Spatial Data Management
 Time Series and Historical Data Management
Slide 2-
79

Database System Environment


 DBMS Component modules
 Database System Utilities
 Tools, Application Environments and communication Facilities
Components of a DBMS
 Query processor
 Database manager
 File manager
 DML preprocessor
 DDL compiler
 Catalog manager
Components of Database Manager
 Authorization control
 Command processor
 Integrity checker
 Query optimizer
 Transaction manager
 Scheduler
 Recovery manager
 Buffer manager
Slide 2-
82

Typical DBMS Component Modules


DBMS structure
Main components
 User
 Query processor
 Storage manager
 Disk storage
© Prof. Navneet Goyal,
Slide 2-
85

Database System Utilities


 To perform certain functions such as:
 Loading data stored in files into a database. Includes data conversion
tools(eg Cincom’s SUPRA Server SQL).
 Backing up the database periodically on tape.
 Reorganizing database file structures.
 Report generation utilities.
 Performance monitoring utilities.
 Other functions, such as sorting, user monitoring, data compression, etc.
Slide 2-
86

Other Tools
 Data dictionary / repository:
 Used to store schema descriptions and other information such as
design decisions, application program descriptions, user information,
usage standards, etc. Information repository
 Active data dictionary is accessed by DBMS software and users/DBA.
 Passive data dictionary is accessed by users/DBA only.
Slide 2-
87
Slide 2-
88

 In the case of a table, data dictionary provides information about


 Its name
 Security information like who is the owner of the table, when was it
created, and when it was last accessed.
 Physical information like where is the data stored for this table
 Structural information like its attribute names and its datatypes,
constraints and indexes. 
Slide 2-
89

 data dictionary would contain


 The definitions of all database objects like tables, views, constraints, indexes,
clusters, synonyms, sequences, procedures, functions, packages, triggers etc
 It stores the information about how much space is allocated for each object
and how much space has been used by them
 Any default values that a column can have are stored
 Database user names  - schemas
 Access rights for schemas on each of the objects
 Last updated and last accessed information about the object
Slide 2-
90

Data dictionary command

SELECT * FROM USER_TABLES; -- this query will not list any owner column as it itself is the owner of tables
SELECT * FROM ALL_TABLES;
SELECT * FROM DBA_TABLES;
Slide 2-
91

Classification of DBMS
W ha t Are th e S tep s i n D ata bas e D e s ig n?

 Step 1: Gather Business Requirements


 Step 2: Understand Business Roadmap
 Step 3: Identify Entities and Attributes
 Step 4: Identify Relationships
 Step 5: Create a Logical ER Diagram
 Step 6: Validate the Logical ER Diagram
 Step 7: Create a Physical ER diagram
 Step 8: Validate the Physical ER Diagram
 Step 9: Fix Issues With the Physical ER Diagram
 Step 10: Generate the DDL Scripts for Deploying the Model

Dr. M. Premalatha, VIT Chennai


References
1. Fundamentals Database Systems, Elmasri, Navathe, 7 th Edition,
Pearson Publication
Thank You…

You might also like