This document discusses data modeling and summarizes that it involves more than just creating diagrams. It involves automating tasks like applying naming standards, adding standard audit columns, and checking designs meet standards. The document highlights how tools can extract statistics to estimate database growth, manage schema versions, and generate JSON. It emphasizes that data modeling requires understanding database dependencies and connections to other systems. A variety of data modeling tools are mentioned but choosing the right tools carefully is important.

1. Data Modelling
It’s a lot more than drawing diagrams
George McGeachie
Metadata Matters Limited

2. My lightning talk at PG day in 2014
(I liked that venue – Horwood House)
My entry in the 2nd Quadrant
blog last week – used example
of automating Data Vault
design and creation
https://blog.2ndquadrant.com/data-modelling-lot-just-diagram/
2
This is my favourite theme

3. The right tool can
give you a lot more
than just this messy
Diagram
– would you want to
work with this
diagram?
3
This is my favourite theme

4. A data model is a lot more than just a Diagram
4
This is my favourite theme

5.  Check against your design standards
 The tedious stuff, like making sure all your
tables have the standard audit columns
 Do you need JSON?
 How much will this DB grow?
 Managing (and comparing) schema, table &
column versions
 Building Data Vaults – see 2nd Quadrant blog
5
Automate tasks – before you
build the database

6. Available automation
A Contextual menu is one way of
accessing automation – check the
model, export JSON to a file, apply
Naming Standards, adding audit
columns

7. Add your own model
checks, along with
automatic fixing for
those problems if
possible
(e.g. adding
surrogate key)
7
Check your design meets your
design standards

8. 8
Make sure all your tables have
the standard audit columns
Don’t blink or you’ll miss it

9. 9
The PDM – without audit columns

10. 10
Less than 2 seconds later …

11. 11
Do you need JSON?
{
"Name" : "Departments",
"Code" : "Departments",
"Fully Qualified Name" : "Group0.Departments",
"Fully Qualified Code" : "Group0.Departments",
"Owner" : "Group0",
"Object Type" : "Table",
"id" : "8731F3EE-8E53-46C6-A873-81C522F51717",
"description" : "contains the names and heads of th
"note" : "<NONE>",
"Columns" :
[
{
"Name" : "DepartmentID",
"Code" : "DepartmentID",
"Fully Qualified Name" : "Departments
"Fully Qualified Code" : "Group0.Depa
"Object Type" : "Column",
"id" : "D23F6064-87A8-4D1D-92D0-70F35
"description" : "short one",
"note" : "<NONE>",
"Data Type" : "INT4",
"Length" : "4",
"Precision" : "0",
"Primary?" : "TRUE",
"FK?" : "FALSE",
"Mandatory?" : "TRUE",

12.  Extract current statistics, define growth rates
12
How much will this database
grow?

13. Estimate of the size of the Database "PhysicalDataModel_1"...
Number Estimated size Object
------------------------- ----------------------- ----------------------------------------
------------
1,556 312 KB Table "Contacts"
17,370 3,475 KB Table "Customers"
917 KB Index "IX_customer_name"
130 7 KB Table "Departments"
1,945 390 KB Table "Employees"
182 13 KB Table "FinancialCodes"
2,179 39 KB Table "FinancialData"
259 130 KB Table "MarketingInformation"
259 KB Long data types
274 KB Index "MarketingTextIndex"
1,379 9,651 KB Table "Products"
9,650 KB Long data types
34 KB Index "IX_product_name"
60 KB Index "IX_product_description"
41 KB Index "IX_product_size"
41 KB Index "IX_product_color"
28,453 619 KB Table "SalesOrderItems"
382,637,520 11,595,077 KB Table "SalesOrders"
3,268 467 KB Table "SpatialContacts"
467 25 KB Table "SpatialShapes"
------------------------- ----------------------- ----------------------------------------
------------
11,621,481 KB Total estimated space
The data will be distributed on the following tablespaces:
Estimated size Tablespace
----------------------- ----------------------------------------------
1,367 KB system
13
Estimate Database size

14.  Write your own estimation script
14
If you don’t like the way it’s
done

15.  Branching
 Comparing
versions
15
Versioning

16.  Check models into the
repository, but don’t
update the mainline until
they’ve been approved
16
Check in model for peer review

17. 17
Integrate the 2nd Branch back
into the 1st Branch
Models updated
with selected
changes
Still able to access version 1

18. 18
Simon and Hannu
say …
Page 53
• Understand Database
Dependencies
◦ e.g. Table  View  Procedure
I only have the first edition of this
excellent book

19.  ETL Jobs
 Forms and Reports
 Applications
 XML Message Schemas
 Regulatory Requirements
 Business Processes
 Use Cases
 JIRA tickets
etc.
19
Databases have connections

20. 20
Choose your tools carefully
What Tools are there?
The big 3
ERwin, ER/Studio, PowerDesigner
Others
Dezign
Sparx EA
ModelRight
Silverrun
IBM Infosphere Data Architect
Toad Data Modeller
might not all support PG

21. George McGeachie
Co-author of “Data Modeling Made Simple with
PowerDesigner”, data modeller and strategist,
SAP PowerDesigner trainer, and data modelling
tool junkie.
@metadatajunkie
Blog – metadatajunkie.wordpress.com
https://www.linkedin.com/in/georgemcgeachie/
George.McGeachie@MetadataMatters.com
Mobile: +44 (0) 794 293 0648