the universal database design the future of data for database architects

13
The Universal Database Design The Future of Data For Database Architects

Upload: constance-martin

Post on 20-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: The Universal Database Design The Future of Data For Database Architects

The Universal Database Design

The Future of Data

For Database Architects

Page 2: The Universal Database Design The Future of Data For Database Architects

To handle objects effectively, you need to be able to relate any entity to any other entity, but this is difficult when they are separated into different entity tables.

Primary Entity Key

Relationship Type

Secondary Entity

Key

(Fan23) Type Of (AcmeFan)

(Fan23) Contains (Motor23)

(Fan23) Connected To

(Wire 14)

Fan Table

Motor Table

Wire Table

Primary /

Secondary

FansMotor

sWires

Fans X X X

Motors

X X X

Wires X X X

This chart shows that to relate the entities of an N=3 number of tables to each other, there are N2=9 number of combinations – a measure of complexity.

Page 3: The Universal Database Design The Future of Data For Database Architects

EntityKey

NameManu

fLengt

h

Length

UnitSize

Size Unit

XX

Unit

(AcmeFan)

Acme Fan

Acme

(Fan23) Fan23 Acme 13 in Small

(Motor23)

Motor23 Nadir 15 kW 30 %

(Wire14)

Wire14 Nadir 10 ft 20 mm2 0.001 Ω

Page 4: The Universal Database Design The Future of Data For Database Architects

Because database tables are custom-designed and crafted to match the applications they support, they are isolated from each other.

Accounting

Accounting Data

Analysis

Analysis Data

Facilities

Facility Data

Purchasing

PurchasingData

Facility DataFacility

Data

PurchasingData

PurchasingData

Analysis Data

Accounting Data

Accounting Data

Analysis Data

Accounting Data

PurchasingData

PurchasingData

PurchasingData

Facility Data

Facility Data

PLM Data

CAD Data

Analysis Data

Facilities Data

Planning Data

Purchasing Data

Analysis

PLM

CAD

Facilities

Planning

Purchasing

Integration leads to an N2 number of point-to-point translations and increased developmental gridlock.

Because most changes are structural, it increases the cost of change, including the transition (or loss) of legacy data.

Page 5: The Universal Database Design The Future of Data For Database Architects

The General Relation Table uses foreign keys from a General Entity Table holding the entity and relationship types.

Primary Entity Key

Relationship Type

Key

Secondary Entity

Key

(Fan23) (TypeOf) (AcmeFan)

(Fan23) (Contains) (Motor23)

(Fan23) (ConnectedTo)

(Wire 14)

To handle object data and other types, we need to increase the flexibility of relationships, but without increasing the complexity.

As shown previously, complexity of a system is proportional to the number of different types of tables squared(N2). To reduce the complexity, it is very effective to reduce the number of table types.

A solution starts with defining a General Relation Table to handle any standard relationship between two entities.

Page 6: The Universal Database Design The Future of Data For Database Architects

Entity Key Name ManufLengt

h

Length

UnitSize

Size Unit

XX

Unit

(AcmeFan) Acme Fan Acme

(Fan23) Fan23 Acme 13 in Small

(Motor23) Motor23 Nadir 15 kW 30 %

(Wire14) Wire14 Nadir 10 ft 20 mm2 0.001 Ω

(TypeOf) Type Of

(Contains) Contains

(ConnectedTo)

Connected To

A General Relation Table requires entities and relationship types to be from the same table, the General Entity Table.

Combining all entities in the same table lets any entity have any attribute, but generates more unused space as is.

Page 7: The Universal Database Design The Future of Data For Database Architects

Using normalization, attribute columns can be replaced with relationships, eliminating the empty space, and allowing multiple values for each attribute.

Primary Entity Key

Relationship Type

Key

Secondary Entity

Key

(Fan23) (TypeOf) (AcmeFan)

(Fan23) (Contains) (Motor23)

(Fan23) (ConnectedTo)

(Wire14)

(AcmeFan)

(Manuf) (Acme)

(Fan23) (Manuf) (Acme)

(Motor23) (Manuf) (Nadir)

(Wire14) (Manuf) (Nadir)

Entity Key Name

(AcmeFan) Acme Fan

(Fan23) Fan23

(Motor23) Motor23

(Wire14) Wire14

(TypeOf) Type Of

(Contains) Contains

(ConnectedTo)

Connected To

(Manuf) Manuf

Page 8: The Universal Database Design The Future of Data For Database Architects

Count

42Part123

PartNo

Parts Catalog Inventory Table The old design pattern holds values

whose meaning are dependent on the row and column positions in each table. This leads to separate, hard-coded, custom-built functions to handle each different table and column.

The new design pattern holds small, atomic pieces of Equal Format Data in a standard container, called an Equal Format Database. This leads to standard, reusable functions with powerful data management capabilities across all “columns”.

Part123 Count 42

Equal Format Data Atom

Equal Format

Database

Page 9: The Universal Database Design The Future of Data For Database Architects

To see the differences in normalization patterns, first examine the statistics of the entities and attributes used.

Fans

Motors

Wires

The old design method uses the pattern of data to define separate tables that match the groupings, each with some of the possible attributes.

The new design method keeps everything in the same “table”, with a full selection of all possible attributes – past, present and future.

Fan Table

Motor Table

Wire Table

Old

New

Page 10: The Universal Database Design The Future of Data For Database Architects

Entity-Relationship (E-R) Triplets have some limitations. They can be difficult to use for some data. It would help to expand past triplets, but we need a larger pattern to guide us.

Subject Key

Verb Key Object Key

(Fan23) (TypeOf) (AcmeFan)

(Fan23) (Contains) (Motor23)

(Fan23) (ConnectedTo)

(Wire14)

(AcmeFan) (Manuf) (Acme)

(Fan23) (Manuf) (Acme)

(Motor23) (Manuf) (Nadir)

(Wire14) (Manuf) (Nadir)

The first step in improving triplets is to convert the entity-relationship triplets to Semantic Triplets. This only requires a name change to the columns, making each row into a Sentence. This concept lays the foundation of the next steps.

Page 11: The Universal Database Design The Future of Data For Database Architects

Sentence Key

Syntax Key Phrase Key

(S1) (Subject) (Fan23)

(S1) (Verb) (TypeOf)

(S1) (Object) (AcmeFan)

(S2) (Subject) (Fan23)

(S2) (Verb) (Contains)

(S2) (Object) (Motor23)

(S3) (Subject) (Fan23)

(S3) (Verb) (ConnectedTo)

(S3) (Object) (Wire14)

(S4) (Subject) (AcmeFan)

(S4) (Verb) (Manuf)

(S4) (Object) (Acme)

Another normalization step moves each phrase to its own row, allowing more phrases per sentence and more phrases per syntax position.

Now you can scan through “tables” and “columns” as easily as rows.

Controls can be added for special capabilities, such as nondestructive changes, point-in-time storage, with less locking problems.

Page 12: The Universal Database Design The Future of Data For Database Architects

Equal Format

Database

Analysis

PLM

Facilities

CAD Planning

Purchasing

PLM Data

CAD Data

Analysis Data

Facilities Data

Planning Data

Purchasing Data

Analysis

PLM

CAD

Facilities

Planning

Purchasing

The old design pattern leads to an N2 number of point-to-point translations, leading to developmental gridlock.

The new design pattern reduces the burden of point-to-point translations, providing a uniform container, a uniform pipeline, and simpler systems.

Page 13: The Universal Database Design The Future of Data For Database Architects

EFD

EFD

EFD

EFD

EFD

EFD

EFD

Analysis

PLM

Facilities

CAD Planning

Purchasing

EFDEFD

Equal Format Database containers can be grouped together to take advantage of many scaling techniques, without altering the data atoms moved between them.

Built on standard database systems, Equal Format Databases are easily integrated with legacy data in various ways.

ProjectSystem

SecuritySystem

DataSystem

VendorSystem

CustomerSystem

Legacy Database

Legacy Database