You are on page 1of 39

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

Typical Learning Curve yp g Graphics Standards Basic Definitions Modes f G hi Operations M d of Graphics O i User Interface Software Modules Modeling and Viewing So t a e ocu e tat o Software Documentation Software Development Efficient use of CAD Software
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 2

## Typical Learning Curve for CAD

Knowledge g Gained STEEP CURVE

Further training and mastering Confusion zone: slow learning, not that steep

## Initial learning period

I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

Time
3

Data Structure
Formal Definition: A data structure is a set of data items or elements that are related to each other by a set of relations. In CAD/CAM, a data structure is a scheme, logic, or sequence of steps to achieve graphics, non-graphics or programming goal Three different types of data structures for CAD:
Based on Edges Based on Vertices Based on Blocks
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 4

## Data Structure (contd.)

B
2

A B1 C

8 3

E B2 G

F
7

THE OBJECT

A
1, 1 A& B

B
2, 2 B& C

C
3, 3 C& D

D E F Set of edges
4, 4 A&D 5, 5 E 6, 6 E& F

G
7, 7 F& G 8, 8 G

Data Structure based on edges (read as this vertex shared by these edges )

1
A, 1&4

2
B, 1&2

4 5 6 Set of vertices
D, 3&4 E, 5&6 F, 6&7

7
G, 7&8

C, 2&3

Data t D t structure b t based on vertices (read as this edge has these vertices) d ti

## B1 B2 UNION Data t t D t structure based on blocks b d bl k

I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 5

Database
It may be defined as an organized collection of graphics y g g and non-graphics data stored on secondary storage in the computer. The objective is to collect and maintain data in a central storage s that it will be available for operations and decision making. A properly developed database satisfies the following requirements:
Eliminate redundancy: both design and manufacturing departments share the same database Enforce standards: data interchange and migration becomes easy Apply security restrictions: using login/password for each user Maintain integrity: for accuracy and consistency Balance conflicting requirements: aim at overall best performance, for example, both design and manufacturing, not either alone
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 6

Relational database Hierarchical database Network d t b N t k database Object oriented database

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

Database Models
Relational Database Model
Background
E. F. Codd developed the relational model in 1970.
Conceptually simple but versatile Major breakthrough for both users and designers

## Requires more computing power

Considered impractical in the 1970s Modern computers (even PCs) are powerful enough to handle relational databases.

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

Database Models
Relational Database Model
Basic Structure
Relational DataBase Management System (RDBMS)
Relational database is percei ed b the user as a perceived by ser collection of tables in which data are stored. Each table consists of series of row/column intersections. Tables (or relations) are related to each other by sharing a common entity characteristic. The relationship type is often shown in a relational schema. A table yields complete data and structural independence because it is a purely logical structure.
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 9

Database Models
R l ti Relational D t b l Database M d l Model

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

10

Point 1 2

Y
Line Start End Point point

Surfa ce

X1 Y1 X2 Y2 X3 Y3 X4 Y4 X5 X6 X7 X8 Y5 Y6 Y7 Y8

A B C D E F G D

## Line Line Li Line Line Line Line Line Line

3 4 5 6 7 8

A B C D E F G

1 1 2 3 5 6 7

4 2 3 4 6 7 8

Relation POINT

Relation LINE/CURVE

Relation SURFACE
11

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

Database Models
Relational Database Model
Data independence and structural independence Easy to design the database and to manage its contents t t Less programming effort required Powerful and flexible query capability:
Structured Query Language (SQL) Fourth Generation Language (4GL) Specify what to do not how to do Introduced by IBM in 1974

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

12

Database Models
Relational Database Model

RDBMS requires substantial hardware and operating system overhead. It tends to be slower than other database systems.
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 13

Database Models

## Hierarchical Database Model

Background
GUAM (Generalized Update Access Method) was developed by North American Rockwell to simplify parts inventory management for the Apollo project. j t Information Management System (IMS) -- Jointly developed by IBM and Rockwell. Data records are organized in an inverted (upsidedown) tree structure -- hierarchical structure.
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 14

Database Models

15

Object (root)

S1

S2

Surface level

Edge level

X1

Y1

X4

Y4

X5

Y5 X4 Y4

16

Database Models

## Hierarchical Database Model

Basic Structure
Collection of records (segments) organized to conform to the upside-down tree structure. One-to-Many (1:M) Relationship
Each parent can have many children children. Each child has only one parent. Example:

## A tree structure is represented as a hierarchical path on the computers storage media.

Preorder (Top down) traversal-more popular Postorder (Bottom up) traversal:

With preorder traversal frequently accessed segments are placed close to the left side of the tree to minimize access time. time
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 17

Database Models

## Hierarchical Database Model

Data sharing and security provision Data independence -- Reduced programming and maintenance effort Database integrity- a child must have a parent Efficiency dealing with a large database containing data ith d t with predominantly 1 M relationships - many d i tl 1:M l ti hi business applications fall in this category

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

18

Database Models
Hierarchical Database Model
Requirement of knowledge of physical level of data storage Inability to represent relationships that do not conform to the hierarchical 1:M standard Applications programming is complex - programmer must know the database structure and how to traverse it Lack of ad hoc query capability for end users ac o oc que y capab ty o e d use s Lack of standard concepts and implementation (No standard was developed)-- limited portability Requires extensive programming activities to use the database - Most serious problem

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

19

Database Models
Network Database Model
Background
CODASYL (Conference on Data Systems Language) group created DataBase Task Group (DBTG) in 1971 to develop standards for a database environment. DBTG specified three crucial database components:
Network schema defines the conceptual organization of the entire database as viewed by the database administrator. Subschema defines the portion of the database as seen by the p y applications programs. Data Management Language defines the data characteristics and the data structure and to manipulate the data.

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

20

Database Models
Network Database Model
Background
Th Three DBTG d t management language components: data tl t
Schema Data Definition Language (DDL) - used by DBA to define schema components S b h Subschema D t D fi iti L Data Definition Language - used b application d by li ti programs to define part of the schema to be used by the program Data Manipulation Language - allows manipulation of the database contents

ANSI SPARC (Standards Planning And Requirements Committee) augmented the database standards in 1975. ) g A popular network DBMS is Computer Associates IDMS/R

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

21

Database Models
N t Network D t b k Database M d l Model
Basic Structure
S -- A relationship i called a set. E h set i Set l i hi is ll d Each is composed of at least two record types: an owner (p (parent) record and a member (child) record. ) ( )

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

22

Database Models
Network Database Model
Relationships among the records are decomposed into a series of sets sets.

23

S1

S2 Surface level

Edge level

Vertex level

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

24

Database Models
Network Database Model
Easier implementation of M:N relationships More flexible data access compared to Hierarchical model - An application can access an owner and all the members within the set, one can also access owner from a member. Enforced data integrity - owner record must be defined before defining member records Data independence through the DBMS
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 25

Database Models
Network Database Model
Very complex structure from the application programmers point of view Difficult to design and use properly - because of the navigational nature of the data structure Difficult to make changes in a database - no structural independence

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

26

Database Models
OO Database Model
Objects are abstractions of real-world entities
Example: Student, Invoice, Employee

Objects capture both attribute and behavior (methods) Objects with similar characteristics are grouped together as a class Classes are organized in a class hierarchy A subclass inherits the attributes and methods from its superclass
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 27

Database Models
OO Database Model
Provides a richer modeling language - captures attributes, methods, and class hierarchies Useful in niche application areas such as CAD/CAM

Data access method resembles the navigational style Lack of standardization
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 28

OBJECT

SUB-OBJECT B1

SUB-OBJECT B2

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

29

Multiple engineering applications from p g g conceptual design to manufacturing operations Dynamic modification and extension of the database and its associativity

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

30

The iterative nature of design This nature design. is not common in business data processing. processing CAD d t b database management systems t t must support the tentative, iterative and evolutionary nature of th d i process. l ti t f the design

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

31

Design versions and levels of detail detail. CAD databases must provide a capability for storage and management of multiple design solutions that may exist for a particular design. There is seldom a unique solution to a design problem there may exist several optimal solutions.
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 32

Concurrent and multiple users must be supported from the database. Large design projects usually multiple designers working simultaneously on d i ki i lt l multiple aspects of a project

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

33

Temporary database support support. D Due t th it ti to the iterative nature of d i t f design, earlier generated data may not be committed t th d t b itt d to the database until th d i til the design process is completed.

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

34

Free design sequence sequence. Th d t b The database system should not i t h ld t impose constraints on the designer to follow because diff b different d i t designs require diff i different t sequences.

## I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani

35

Easy access access. Application program requiring data from a CAD database should not require extensive knowledge of the database structure to extract the data needed needed. This is important in customizing CAD systems t for f specific ifi design d i and d manufacturing procedure.
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 36

Easy to learn Easy to work with Have macro commands Have its own embedded programming language Have an open database Be compatible with other CAD/CAM and analysis program

37

## Major Benefits of a CAD package

Automates repetitive tasks reduces duplicate efforts Allows you to communicate with others via electronic means Makes drawing revisions easier to perform Enable you to customize environment Lets you to create accurate and high-quality drawing Provides impressive presentation Supports a wide selection of hardware
I/C: Dr. Regalla Srinivasa Prakash, Mechanical Engg., B. I. T. S., Pilani 38

Thank you!
Any questions?

39