Vectalis Database modeling style

Vectalis Modeling Style

[email protected]

[SOLVE] How to represent a Complex Database Model (100+ tables) in a clean and traceable manner?

Problem of Modeling the Data Access Layer• You want to Design a really complex Data Model with 100+ tables and many complicate

relations between them. • People often use fancy tools to draw the 100+ tiny tables in a big paper with every relation like a

map.

• The fact is that your co-workers might not fall in love with your beautiful map!The relation lines cross, intersection everywhere. Hard to see the relation between 3 given tables at the 3 corners of the map.The map on the whole will not help. It often make sense only if we zoom in the interesting part, focus only on some small scope tables.

Solution: Vectalis Modeling Style

• Split your map into smaller pieces which make sense.• No need fancy tool to draw your model - PowerPoint is your

friend. • This document will show you How to use PowerPoint to

efficiently design complex data model (hundred of tables) with the Vectalis Modeling Style.

• You only need to know 5 basic operations in PowerPoint:• Copy / Paste• Connect a line to a Rectangle • Right-click on the line, choose a good Connector Types • Ctrl+F to find everything you needs in the DataModel• Select 2 Rectangles, Align them vertically / horizontally center

• When you get used to these skills, PowerPoint will becomes a super-weapons for design / draft / brainstorming your Database Model.

Ingredients

Root

Base

Single

Link

Interface

Base

Single

Link

Instantiable Entity Abstract Entity (with muted color, and no outline)

Interface

- Automatic- Optional- ‘Freezing’

{

AnyAny

I will copy paste these ingredients to draw my data model

Example 1 – Getting Started

They represent the following SQL Tables:

• Company (#CompanyId, Code, Name, Type…)

• Employee (#EmployeeId, CompanyId, FirstName, LastName…)

• Client (#ClientId) /* ClientId = CompanyId or EmployeeId, No other columns is allowed */

• Service (#ServiceId, Description…) /*contains commons properties of ServiceBonds, ServiceFX, ServiceStock*/

• Subscription (#SubscriptionId, ClientId, ServiceId, Date, State...)

• ServiceBonds (#ServiceId, Issuer…) /*join with the Service table to know other properties*/

• ServiceFX(#ServiceId, Currency1, Currency2, Rate…) /*join with the Service table to know other properties*/

• ServiceStock(#ServiceId, Underlying, Source…) /*join with the Service table to know other properties*/

This drawing contains more information than just that…

Company

Client Service

EmployeeSubscription

ServiceBonds

ServiceFX

ServiceStock

- Parent-children Relation- 1 Company has 0..N Employee.- Delete Company = delete all Employee

- Yellow Box = Base-Entity - Green Box = Interface- Entity- Interface-Entity cannot have properties (the Client table can only has 1 column – the clientId)

- Light Yellow Box = Abstract-Entity- Abstract-Entity can have properties

- Inheritance Relation- Any Entity (of any color) can inherit one or several Interface entities

- Inheritance Relation- A base Entity or abstract Entity can only inherit from one (other) Abstract Entity

- Cyan Box = Link-Entity- Link at least 2 entities together.

Example 1 – Explanation (1)They represent the following data structure:

Company

Client

Employee

- Parent-children Relation- 1 Company has 0..N Employee.- Delete Company = delete all Employee

- Yellow Box = Base-Entity - Green Box = Interface- Entity- Interface-Entity cannot have properties (the Client table can only has 1 column – the clientId)

- Inheritance Relation- Any Entity (of any color) can inherit one or several Interface entities

interface Client { getClientId(); }

class Company implements Client { GUID companyId; List<Employee> employees getClient() {return companyId;}

//other properties String Code; String Name; ...}

class Employee implements Client { GUID employeeId; Company company; //not null getClient() {return employeeId;}

//other properties String firstName; String lastName; ...}

As you can guess:

The green line relation tells that- Insert/Delete 1 Company = Insert/Delete 1 Client- Insert/Delete 1 Employee = Insert/Delete 1 Client

The red line arrow tells that- One company contains a list of Employee (1-N).- Employee MUST reference to a parent (Company)- Destroy a Company = Destroy all its Employees

Example 1 – Explanation (2)They represent the following data structure:

interface Client { GUID getClientId(); List<Subscription> getSubscriptions()}

abstract class Service { GUID serviceId; List<Subscription> subscriptions; ...}

class Subscription { GUID subscriptionId; Client client; //not null Service service; //not null}

As you can guess:

- Subscription has 2 parents => it must have 2 Foreign Keys- It must be destroyed if one of parents is destroyed.- The Client #21 links to a Service #53 via one and only one Subscription #18. If there are another Subscription #19 which also link the Client #21 to the Service #53 => something was wrong in your system

Client Service

Subscription

- Cyan Box = Link-Entity- Link at least 2 entities together.

Example 1 – Explanation (end)They represent the following data structure:

abstract class Service { GUID serviceId; //properties String description; ...}

class ServiceBonds extends Service { //properties String Issuer; ...}

class ServiceFX extends Service { //properties String Currency1; String Currency2; double Rate; ...}

class ServiceStock extends Service { //properties String Underlying; String Source; ...}

As you can guess:

- Insert/Delete 1 row in the ServiceBonds table MUST Insert/Delete 1 row in the Service table…

Service

ServiceBonds

ServiceFX

ServiceStock

- Light Yellow Box = Abstract-Entity- Abstract-Entity can have properties

- Inheritance Relation- A base Entity or abstract Entity can only inherit from one (other) Abstract Entity

Single Entity + Reference RelationThey represent the following data structure:

class User { GUID userId; PrivateInfo privateInfo; //not null //other properties Order order; ...}class PrivateInfo { GUID privateInfoId; User user; //not null}

class Product { GUID ProductId; Order order; //can be null}class Order { GUID orderId; Product product; //not null}

- PrivateInfo is a single-child of User (1-1 relation), so that it will be destroyed if the User is destroyed.- Order is a optional-single-child of Product (1-0,1 relation) so that it will be destroyed if the Product is destroyed.- The blue line tells that one or several properties of the User is Order.

As you can guess:

User (#userId, orderId…)PrivateInfo (#privateInfoId, userId, …)Product (#productId, orderId, …)Order (#orderId, productId, …)

User

PrivateInfo

Product

Order

Reference to

Example 2 – Blog Data Model

BloggerRole

PostDateCreationDateLastModifiedTitile (string)Demo (Image)Content (content)

BloggerInvitationRequest

Friend

AcceptInvitation (trigger)DenyInvitation (trigger)Message (string)

RemoveFriend (trigger)

Comment

Nick (string)Blast (string)

CommentWriter

Content (string)SubmitComment (trigger) Date (dateTime)

Content (string)

Can you see the potential redundancy of Friend and InvitationRequest? What about add to the the InvitationRequest a ‘State’ property (State = Accepted, Rejected..) So we can discard the Friend table. Will it better?

Example 3: Guess what it do?

Root

Underlying

BrokerQuote

Subscription

Broadcast

User

Trader

EntityBroker

EntityEntityTrader

Reply

bid: double?ask: double?comment: string?

underlyingderivative: stringparameter: string?reference: string?tradedPrice: double

code: stringname: string

code: stringname: stringemail: stringtel: string

code: stringfirstname: stringlastname: stringgender: Enum(M, F)email: stringtel: string

QuotePrivate bid: double?ask: double?

Example 4 - A more complex Data Model

• Ctrl+F to find entities you are interested to• If you want to see the relation between 3

entities from 3 different pages => add a new page and copy / paste into it:

1. The 3 entities in question (make it bigger)2. A minimum of Other related entities3. The principal relations between them (related arrows)

• Because your co-workers might also interested in the relations between these 3 entities and they will love your new page.

Advantage & Drawback

• (Some) Advantages:• Contains far more information in a cleaner way.• Make your thought more structural because you will design your model base on structural ingredients:

Tree, Link, Single, Inheritance. • Important information is made more relevant => They make more sense.

• Example: let see what is interesting in Subscription (from the above drawings)… Ahh! State• The creation and maintenance of the drawing is quite easy. (IMO, easier than the traditional big map)• PowerPoint is popular and flexible enough, you don’t need other specialize drawing tool.

• In plus, every Entity and its relation can be trace easily with Ctrl+F.

• Drawback:• Require a short training to understand and get used to it• Require to master the 5 basic functions of PowerPoint as represented in the page 2• Accept redundancies information (the same relation might be drew over and over again..) This is the

tradeoff when you split your complex model into many pieces to make it more clear & readable.. • It make you easily come up with over-complex model, because of the limited structural ingredients.

User Product Service

Subscription

versus

FirstName: StringLastName: StringResponsibility: Number

State: String

Description: String

Conclusion

• The Vectalis Modeling style is a well thought way to draw database model.

• Adapted for both small and complex model.

I recommend that you:• Try this method to design your next project • Or Try to draw your existed database in the Vectalis Style

• and don’t be surprised if you will see many Redundancy or Bad design in your current database model.

• You might not need the notion of Interface-Entity (the green things) or the notion of Heritage… but you might invent other ingredients… => Made your own style and… share it with me ;-)

• Sometime you will need to make your own style perhaps with just Link-Entity and Tree-Entity so that You can easily communicate your datamodel to client in a understandable way.

References

• All the idea comes from my precedent experience at Vectalis SARL

• http://www.vectalis.com• The name: Vectalis Modeling Style is to say that Vectalis is the

author of every idea that I presented in this document.

• Modeling Data using structural ingredients (Tree, Link..) is one of the core concept adopted by the DsetaFramework of Vectalis

• http://www.the-dseta-framework.com/fr/index.aspx• I only extracted a part of this philosophy in order to solve only

one very specific problem outside the context of the DsetaFramework:

• How to represent a Complex Database Model in a clean and traceable way?