• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Vectalis modeling style
 

Vectalis modeling style

on

  • 619 views

Solve how to design / modeling complex Database with more than 100+ tables and many relationship.. The Vectalis Style will help you to ...

Solve how to design / modeling complex Database with more than 100+ tables and many relationship.. The Vectalis Style will help you to
1) Think structurally => protect you from odd decision => adding odd columns or relation that nobody would understand!
2) make clean / maintenable / Searchable drawing for your complex data model.

Statistics

Views

Total Views
619
Views on SlideShare
619
Embed Views
0

Actions

Likes
1
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Vectalis modeling style Vectalis modeling style Presentation Transcript

    • Vectalis Modeling Style duongphuhiep@gmail.com [SOLVE] How to represent a Complex Database Model (100+ tables) in a clean and traceable way?
    • 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 would 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 different corners of the map. • The map on the whole will not help. It will make sense only if we zoom in each part of it.
    • Solution • 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. • The Vectalis Modeling Style is a well-thought way to draw complex Data Model & detect redundancy.. • 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 Employee Subscription 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 Relation They 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 Post DateCreation DateLastModified Titile (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 Entity EntityTrader Reply bid: double? ask: double? comment: string? underlying derivative: string parameter: string? reference: string? tradedPrice: double code: string name: string code: string name: string email: string tel: string code: string firstname: string lastname: string gender: Enum(M, F) email: string tel: 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 entities 3. 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 clear and 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 time 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.. User Product Service Subscription versus FirstName: String LastName: String Responsibility: 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?