You are on page 1of 15

Table of Contents

1. What is data modeling?


o How are data models used in practice?
o What about conceptual models?
o Common data modeling notations
2. How to model data
o Identify entity types
o Identify attributes
o Apply naming conventions
o Identify relationships
o Apply data model patterns
o Assign eys
o !ormali"e to reduce data redundancy
o #enormali"e to improve performance
$. %volutionary&agile data modeling
4. How to become better at modeling data

1. What is Data Modeling?
#ata modeling is the act of e'ploring data(oriented structures. )ie other modeling artifacts data models
can be used for a variety of purposes* from high(level conceptual models to physical data models. +rom
the point of view of an ob,ect(oriented developer data modeling is conceptually similar to class modeling.
With data modeling you identify entity types whereas with class modeling you identify classes. #ata
attributes are assigned to entity types ,ust as you would assign attributes and operations to classes.
-here are associations between entities* similar to the associations between classes . relationships*
inheritance* composition* and aggregation are all applicable concepts in data modeling.
-raditional data modeling is different from class modeling because it focuses solely on data . class models
allow you to e'plore both the behavior and data aspects of your domain* with a data model you can only
e'plore data issues. /ecause of this focus data modelers have a tendency to be much better at getting
the data 0right1 than ob,ect modelers. However* some people will model database methods 2stored
procedures* stored functions* and triggers3 when they are physical data modeling. It depends on the
situation of course* but I personally thin that this is a good idea and promote the concept in my 45) data
modeling profile 2more on this later3.
Although the focus of this article is data modeling* there are often alternatives to data(oriented artifacts
2never forget Agile 5odeling6s 5ultiple 5odels principle3. +or e'ample* when it comes to conceptual
modeling 785 diagrams aren6t your only option . In addition to )#5s it is 9uite common for people to
create 45) class diagrams and even Class 8esponsibility Collaborator 2C8C3 cards instead. In fact* my
e'perience is that C8C cards are superior to 785 diagrams because it is very easy to get pro,ect
staeholders actively involved in the creation of the model. Instead of a traditional* analyst(led drawing
session you can instead facilitate staeholders through the creation of C8C cards.

1.1 How are Data Models Used in Practice?
Although methodology issues are covered later* we need to discuss how data models can be used in
practice to better understand them. :ou are liely to see two basic styles of data model;
Conceptual data models. -hese models* sometimes called domain models* are typically used
to e'plore domain concepts with pro,ect staeholders. Conceptual data models are often created
as the precursor to )#5s or as alternatives to )#5s.
ogical data models !DMs". )#5s are used to e'plore the domain concepts* and their
relationships* of your problem domain. -his could be done for the scope of a single pro,ect or for
1
your entire enterprise. )#5s depict the logical entity types* typically referred to simply as entity
types* the data attributes describing those entities* and the relationships between the entities.
Ph#sical data models !PDMs". <#5s are used to design the internal schema of a database*
depicting the data tables* the data columns of those tables* and the relationships between the
tables. -he focus of this article is on physical modeling.
Although )#5s and <#5s sound very similar* and they in fact are* the level of detail that they model can
be significantly different. -his is because the goals for each diagram is different . you can use an )#5 to
e'plore domain concepts with your staeholders and the <#5 to define your database design. +igure 1
presents a simple )#5 and +igure 2 a simple <#5* both modeling the concept of customers and addresses
as well as the relationship between them. /oth diagrams apply the /arer notation* summari"ed below.
!otice how the <#5 shows greater detail* including an associative table re9uired to implement the
association as well as the eys needed to maintain the relationships. 5ore on these concepts later. <#5s
should also reflect your organi"ation6s database naming standards* in this case an abbreviation of the
entity name is appended to each column name and an abbreviation for 0!umber1 was consistently
introduced. A <#5 should also indicate the data types for the columns* such as integer and char2=3.
Although +igure 2 does not show them* looup tables 2also called reference tables or description tables3
for how the address is used as well as for states and countries are implied by the attributes
ADDR_USAGE_CODE* STATE_CODE* and COUNTRY_CODE.

$igure 1. % simple logical data model.

$igure &. % simple ph#sical data model.
An important observation about +igures 1 and 2 is that I6m not slavishly following /arer6s approach to
naming relationships. +or e'ample* between Customer and Address there really should be two names
0%ach C4>-75%8 may be located in one or more A##8%>>%>1 and 0%ach A##8%>> may be the site of
one or more C4>-75%8>1. Although these names e'plicitly define the relationship I personally thin that
they6re visual noise that clutter the diagram. I prefer simple names such as 0has1 and then trust my
2
readers to interpret the name in each direction. I6ll only add more information where it6s needed* in this
case I thin that it isn6t. However* a significant advantage of describing the names the way that /arer
suggests is that it6s a good test to see if you actually understand the relationship . if you can6t name it
then you liely don6t understand it.
#ata models can be used effectively at both the enterprise level and on pro,ects. %nterprise architects will
often create one or more high(level )#5s that depict the data structures that support your enterprise*
models typically referred to as enterprise data models or enterprise information models. An enterprise
data model is one of several views that your organi"ation6s enterprise architects may choose to maintain
and support . other views may e'plore your networ&hardware infrastructure* your organi"ation structure*
your software infrastructure* and your business processes 2to name a few3. %nterprise data models
provide information that a pro,ect team can use both as a set of constraints as well as important insights
into the structure of their system.
<ro,ect teams will typically create )#5s as a primary analysis artifact when; their implementation
environment is predominantly procedural in nature* for e'ample they are using structured C7/7) as an
implementation language. )#5s are also a good choice when a pro,ect is data(oriented in nature* perhaps
a data warehouse or reporting system is being developed 2having said that* e'perience seems to show
that usage(centered approaches appear to wor even better3. However )#5s are often a poor choice
when a pro,ect team is using ob,ect(oriented or component(based technologies because the developers
would rather wor with 45) diagrams or when the pro,ect is not data(oriented in nature. As Agile
5odeling advises* apply the right artifact2s3 for the ,ob. 7r* as your grandfather liely advised you* use
the right tool for the ,ob.
When a relational database is used for data storage pro,ect teams are best advised to create a <#5s to
model its internal schema. 5y e'perience is that a <#5 is often one of the critical design artifacts for
business application development pro,ects.

&.&. What %bout Conceptual Models?
Halpin 22??13 points out that many data professionals prefer to create an 7b,ect(8ole 5odel 27853* an
e'ample is depicted in +igure $* instead of an )#5 for a conceptual model. -he advantage is that the
notation is very simple* something your pro,ect staeholders can 9uicly grasp* although the disadvantage
is that the models become large very 9uicly. 785s enable you to first e'plore actual data e'amples
instead of simply ,umping to a potentially incorrect abstraction . for e'ample +igure $ e'amines the
relationship between customers and addresses in detail. +or more information about 785* visit
www.orm.net.

$igure '. % simple (b)ect*+ole Model.
5y e'perience is that people will capture information in the best place that they now. As a result I
typically discard 785s after I6m finished with them. I sometimes user 785s to e'plore the domain with
pro,ect staeholders but later replace them with a more traditional artifact such as an )#5* a class
diagram* or even a <#5. As a generali"ing specialist* someone with one or more specialties who also
3
strives to gain general sills and nowledge* this is an easy decision for me to mae@ I now that this
information that I6ve ,ust 0discarded1 will be captured in another artifact . a model* the tests* or even the
code . that I understand. A specialist who only understands a limited number of artifacts and therefore
0hands(off1 their wor to other specialists doesn6t have this as an option. !ot only are they tempted to
eep the artifacts that they create but also to invest even more time to enhance the artifacts.
Aenerali"ing specialists are more liely than specialists to travel light.

&.'. Common Data Modeling ,otations
+igure B presents a summary of the synta' of four common data modeling notations; Information
%ngineering 2I%3* /arer* I#%+1C* and the 4nified 5odeling )anguage 245)3. -his diagram isn6t meant to
be comprehensive* instead its goal is to provide a basic overview. +urthermore* for the sae of brevity I
wasn6t able to depict the highly(detailed approach to relationship naming that /arer suggests. Although I
provide a brief description of each notation in -able 1 I highly suggest #avid Hay6s paper A Comparison of
#ata 5odeling -echni9ues as he goes into greater detail than I do.

$igure -. Comparing the s#nta. of common data modeling notations.
4

Table 1. Discussing common data modeling notations.
,otation Comments
I%
-he I% notation 2+inelstein 1DED3 is simple and easy to read* and is well suited for high(
level logical and enterprise data modeling. -he only drawbac of this notation* arguably
an advantage* is that it does not support the identification of attributes of an entity. -he
assumption is that the attributes will be modeled with another diagram or simply
described in the supporting documentation.
5
/arer
-he /arer notation is one of the more popular ones* it is supported by 7racle6s toolset*
and is well suited for all types of data models. It6s approach to subtyping can become
cluny with hierarchies that go several levels deep.
I#%+1C
-his notation is overly comple'. It was originally intended for physical modeling but has
been misapplied for logical modeling as well. Although popular within some 4.>.
government agencies* particularly the #epartment of #efense 2#o#3* this notation has
been all but abandoned by everyone else. Avoid it if you can.
45)
-his is not an official data modeling notation 2yet3. Although several suggestions for a
data modeling profile for the 45) e'ist* none are complete and more importantly are not
0official1 45) yet. However* the 7b,ect 5anagement Aroup 275A3 in #ecember 2??=
announced an 8+< for data(oriented models.

'. How to Model Data
It is critical for an application developer to have a grasp of the fundamentals of data modeling so they can
not only read data models but also wor effectively with Agile #/As who are responsible for the data(
oriented aspects of your pro,ect. :our goal reading this section is not to learn how to become a data
modeler* instead it is simply to gain an appreciation of what is involved.
-he following tass are performed in an iterative manner;
Identify entity types
Identify attributes
Apply naming conventions
Identify relationships
Apply data model patterns
Assign eys
!ormali"e to reduce data redundancy
#enormali"e to improve performance

Fery good practical boos about data modeling
include Goe Celo6s #ata H #atabases and #ata
5odeling for Information <rofessionals as they both
focus on practical issues with data modeling. -he
#ata 5odeling Handboo and #ata 5odel <atterns
are both e'cellent resources once you6ve mastered
the fundamentals. An Introduction to #atabase
>ystems is a good academic treatise for anyone
wishing to become a data specialist.

'.1 /dentif# 0ntit# T#pes
An entity type* also simply called entity 2not e'actly accurate terminology* but very common in practice3*
is similar conceptually to ob,ect(orientation6s concept of a class . an entity type represents a collection of
similar ob,ects. An entity type could represent a collection of people* places* things* events* or concepts.
%'amples of entities in an order entry system would include Customer* Address* Order* Item* and Tax. If
you were class modeling you would e'pect to discover classes with the e'act same names. However* the
6
difference between a class and an entity type is that classes have both data and behavior whereas entity
types ,ust have data.
Ideally an entity should be normal* the data modeling world6s version of cohesive. A normal entity depicts
one concept* ,ust lie a cohesive class models one concept. +or e'ample* customer and order are clearly
two different concepts@ therefore it maes sense to model them as separate entities.

'.& /dentif# %ttributes
%ach entity type will have one or more data attributes. +or e'ample* in +igure 1 you saw that the
Customer entity has attributes such as First Name and Surname and in +igure 2 that the TCUSTOMER
table had corresponding data columns CUST_FIRST_NAME and CUST_SURNAME 2a column is the
implementation of a data attribute within a relational database3.
Attributes should also be cohesive from the point of view of your domain* something that is often a
,udgment call. . in +igure 1 we decided that we wanted to model the fact that people had both first and
last names instead of ,ust a name 2e.g. 0>cott1 and 0Ambler1 vs. 0>cott Ambler13 whereas we did not
distinguish between the sections of an American "ip code 2e.g. D?21?(12$B(=IJE3. Aetting the level of
detail right can have a significant impact on your development and maintenance efforts. 8efactoring a
single data column into several columns can be difficult* database refactoring is described in detail in
#atabase 8efactoring* although over(specifying an attribute 2e.g. having three attributes for "ip code
when you only needed one3 can result in overbuilding your system and hence you incur greater
development and maintenance costs than you actually needed.

'.' %ppl# Data ,aming Con1entions
:our organi"ation should have standards and guidelines applicable to data modeling* something you
should be able to obtain from your enterprise administrators 2if they don6t e'ist you should lobby to have
some put in place3. -hese guidelines should include naming conventions for both logical and physical
modeling* the logical naming conventions should be focused on human readability whereas the physical
naming conventions will reflect technical considerations. :ou can clearly see that different naming
conventions were applied in +igures 1 and 2.
As you saw in Introduction to Agile 5odeling* A5 includes the Apply 5odeling >tandards practice. -he
basic idea is that developers should agree to and follow a common set of modeling standards on a
software pro,ect. Gust lie there is value in following common coding conventions* clean code that follows
your chosen coding guidelines is easier to understand and evolve than code that doesnKt* there is similar
value in following common modeling conventions.

'.- /dentif# +elationships
In the real world entities have relationships with other entities. +or e'ample* customers <)AC% orders*
customers )IF% A- addresses* and line items A8% <A8- 7+ orders. <lace* live at* and are part of are all
terms that define relationships between entities. -he relationships between entities are conceptually
identical to the relationships 2associations3 between ob,ects.
+igure = depicts a partial )#5 for an online ordering system. -he first thing to notice is the various styles
applied to relationship names and roles . different relationships re9uire different approaches. +or
e'ample the relationship between Customer and Order has two names* plaes and is plaed !"* whereas
the relationship between Customer and Address has one. In this e'ample having a second name on the
relationship* the idea being that you want to specify how to read the relationship in each direction* is
redundant . you6re better off to find a clear wording for a single relationship name* decreasing the clutter
on your diagram. >imilarly you will often find that by specifying the roles that an entity plays in a
relationship will often negate the need to give the relationship a name 2although some CA>% tools may
7
inadvertently force you to do this3. +or e'ample the role of !illin# address and the label !illed to are
clearly redundant* you really only need one. +or e'ample the role part o$ that %ine Item has in its
relationship with Order is sufficiently obvious without a relationship name.
$igure 2. % logical data model !/nformation 0ngineering notation".

:ou also need to identify the cardinality and optionality of a relationship 2the 45) combines the concepts
of optionality and cardinality into the single concept of multiplicity3. Cardinality represents the concept of
0how many1 whereas optionality represents the concept of 0whether you must have something.1 +or
e'ample* it is not enough to now that customers place orders. How many orders can a customer place?
!one* one* or several? +urthermore* relationships are two(way streets; not only do customers place
orders* but orders are placed by customers. -his leads to 9uestions lie; how many customers can be
enrolled in any given order and is it possible to have an order with no customer involved? +igure = shows
that customers place one or more orders and that any given order is placed by one customer and one
customer only. It also shows that a customer lives at one or more addresses and that any given address
has "ero or more customers living at it.
Although the 45) distinguishes between different types of relationships . associations* inheritance*
aggregation* composition* and dependency . data modelers often aren6t as concerned with this issue as
much as ob,ect modelers are. >ubtyping* one application of inheritance* is often found in data models* an
e'ample of which is the is a relationship between Item and it6s two 0sub entities1 Ser&ie and 'rodut.
Aggregation and composition are much less common and typically must be implied from the data model*
as you see with the part o$ role that %ine Item taes with Order. 45) dependencies are typically a
software construct and therefore wouldn6t appear on a data model* unless of course it was a very highly
detailed physical model that showed how views* triggers* or stored procedures depended on other aspects
of the database schema.

'.2 %ppl# Data Model Patterns
>ome data modelers will apply common data model patterns* #avid Hay6s boo #ata 5odel <atterns is the
best reference on the sub,ect* ,ust as ob,ect(oriented developers will apply analysis patterns 2+owler
1DDJ@ Ambler 1DDJ3 and design patterns 2Aamma et al. 1DD=3. #ata model patterns are conceptually
closest to analysis patterns because they describe solutions to common domain issues. Hay6s boo is a
very good reference for anyone involved in analysis(level modeling* even when you6re taing an ob,ect
approach instead of a data approach because his patterns model business structures from a wide variety
of business domains.

'.3 %ssign 4e#s
-here are two fundamental strategies for assigning eys to tables. +irst* you could assign a natural ey
which is one or more e'isting data attributes that are uni9ue to the business concept. -he Customer table
of +igure I there was two candidate eys* in this case CustomerNum!er and SoialSeurit"Num!er.
8
>econd* you could introduce a new column* called a surrogate ey* which is a ey that has no business
meaning. An e'ample of which is the AddressID column of the Address table in +igure I. Addresses don6t
have an 0easy1 natural ey because you would need to use all of the columns of the Address table to form
a ey for itself 2you might be able to get away with ,ust the combination of Street and (ipCode depending
on your problem domain3* therefore introducing a surrogate ey is a much better option in this case.

$igure 3. Customer and %ddress re1isited !UM notation".

)etKs consider +igure I in more detail. +igure I presents an alternative design to that presented in +igure
2* a different naming convention was adopted and the model itself is more e'tensive. In +igure I the
Customer table has the CustomerNum!er column as its primary ey and SoialSeurit"Num!er as an
alternate ey. -his indicates that the preferred way to access customer information is through the value
of a person6s customer number although your software can get at the same information if it has the
person6s social security number. -he Customer)asAddress table has a composite primary ey* the
combination of CustomerNum!er and AddressID. A foreign ey is one or more attributes in an entity type
that represents a ey* either primary or secondary* in another entity type. +oreign eys are used to
maintain relationships between rows. +or e'ample* the relationships between rows in the
Customer)asAddress table and the Customer table is maintained by the CustomerNum!er column within
the Customer)asAddress table. -he interesting thing about the CustomerNum!er column is the fact that
it is part of the primary ey for Customer)asAddress as well as the foreign ey to the Customer table.
>imilarly* the AddressID column is part of the primary ey of Customer)asAddress as well as a foreign
ey to the Address table to maintain the relationship with rows of Address.
Although the Lnatural vs. surrogateL debate is one of the great religious issues within the data community*
the fact is that neither strategy is perfect and youKll discover that in practice 2as we see in +igure I3
sometimes it maes sense to use natural eys and sometimes it maes sense to use surrogate eys. In
Choosing a <rimary Mey; !atural or >urrogate? I describe the relevant issues in detail.

'.5 ,ormali6e to +educe Data +edundanc#
#ata normali"ation is a process in which data attributes within a data model are organi"ed to increase the
cohesion of entity types. In other words* the goal of data normali"ation is to reduce and even eliminate
data redundancy* an important consideration for application developers because it is incredibly difficult to
9
stores ob,ects in a relational database that maintains the same information in several places. -able 2
summari"es the three most common normali"ation rules describing how to put entity types into a series of
increasing levels of normali"ation. Higher levels of data normali"ation 2#ate 2???3 are beyond the scope
of this boo. With respect to terminology* a data schema is considered to be at the level of normali"ation
of its least normali"ed entity type. +or e'ample* if all of your entity types are at second normal form
22!+3 or higher then we say that your data schema is at 2!+.
Table &. Data ,ormali6ation +ules.
e1el +ule
+irst normal form 21!+3 An entity type is in 1!+ when it contains no repeating groups of data.
>econd normal form 22!+3 An entity type is in 2!+ when it is in 1!+ and when all of its non(ey attributes
are fully dependent on its primary ey.
-hird normal form 2$!+3 An entity type is in $!+ when it is in 2!+ and when all of its attributes are
directly dependent on the primary ey.

+igure J depicts a database schema in 7!+ whereas +igure E depicts a normali"ed schema in $!+. 8ead
the Introduction to #ata !ormali"ation essay for details.
Why data normali"ation? -he advantage of having a highly normali"ed data schema is that information is
stored in one place and one place only* reducing the possibility of inconsistent data. +urthermore* highly(
normali"ed data schemas in general are closer conceptually to ob,ect(oriented schemas because the
ob,ect(oriented goals of promoting high cohesion and loose coupling between classes results in similar
solutions 2at least from a data point of view3. -his generally maes it easier to map your ob,ects to your
data schema. 4nfortunately* normali"ation usually comes at a performance cost. With the data schema
of +igure J all the data for a single order is stored in one row 2assuming orders of up to nine order items3*
maing it very easy to access. With the data schema of +igure J you could 9uicly determine the total
amount of an order by reading the single row from the Order*NF table. -o do so with the data schema of
+igure E you would need to read data from a row in the Order table* data from all the rows from the
OrderItem table for that order and data from the corresponding rows in the Item table for each order
item. +or this 9uery* the data schema of +igure J very liely provides better performance.

$igure 5. %n /nitial Data 7chema for (rder !UM ,otation".
10
11

$igure 8. % normali6ed schema in ',$ !UM ,otation".
In class modeling* there is a similar concept called Class !ormali"ation although that is beyond the scope
of this article.

'.8 Denormali6e to /mpro1e Performance
!ormali"ed data schemas* when put into production* often suffer from performance problems. -his maes
sense . the rules of data normali"ation focus on reducing data redundancy* not on improving performance
of data access. An important part of data modeling is to denormali"e portions of your data schema to
improve database access times. +or e'ample* the data model of +igure D loos nothing lie the
normali"ed schema of +igure E. -o understand why the differences between the schemas e'ist you must
consider the performance needs of the application. -he primary goal of this system is to process new
orders from online customers as 9uicly as possible. -o do this customers need to be able to search for
items and add them to their order 9uicly* remove items from their order if need be* then have their final
order totaled and recorded 9uicly. -he secondary goal of the system is to the process* ship* and bill the
orders afterwards.

$igure 9. % Denormali6ed (rder Data 7chema !UM notation".
12

-o denormali"e the data schema the following decisions were made;
1. -o support 9uic searching of item information the Item table was left alone.
2. -o support the addition and removal of order items to an order the concept of an OrderItem table
was ept* albeit split in two to support outstanding orders and fulfilled orders. !ew order items
can easily be inserted into the Outstandin#OrderItem table* or removed from it* as needed.
13
$. -o support order processing the Order and OrderItem tables were rewored into pairs to handle
outstanding and fulfilled orders respectively. /asic order information is first stored in the
Outstandin#Order and Outstandin#OrderItem tables and then when the order has been shipped
and paid for the data is then removed from those tables and copied into the Ful$illedOrder and
Ful$illedOrderItem tables respectively. #ata access time to the two tables for outstanding orders
is reduced because only the active orders are being stored there. 7n average an order may be
outstanding for a couple of days* whereas for financial reporting reasons may be stored in the
fulfilled order tables for several years until archived. -here is a performance penalty under this
scheme because of the need to delete outstanding orders and then resave them as fulfilled
orders* clearly something that would need to be processed as a transaction.
B. -he contact information for the person2s3 the order is being shipped and billed to was also
denormali"ed bac into the Order table* reducing the time it taes to write an order to the
database because there is now one write instead of two or three. -he retrieval and deletion
times for that data would also be similarly improved.
!ote that if your initial* normali"ed data design meets the performance needs of your application then it is
fine as is. #enormali"ation should be resorted to only when performance testing shows that you have a
problem with your ob,ects and subse9uent profiling reveals that you need to improve database access
time. As my grandfather said* if it ain6t broe don6t fi' it.

2. 01olutionar#:%gile Data Modeling
%volutionary data modeling is data modeling performed in an iterative and incremental manner. -he
article %volutionary #evelopment e'plores evolutionary software development in greater detail. Agile data
modeling is evolutionary data modeling done in a collaborative manner. -he article Agile #ata 5odeling;
+rom #omain 5odeling to <hysical 5odeling wors through a case study which shows how to tae an agile
approach to data modeling.
Although you wouldn6t thin it* data modeling can be one of the most challenging tass that an Agile #/A
can be involved with on an agile software development pro,ect. :our approach to data modeling will often
be at the center of any controversy between the agile software developers and the traditional data
professionals within your organi"ation. Agile software developers will lean towards an evolutionary
approach where data modeling is ,ust one of many activities whereas traditional data professionals will
often lean towards a big design up front 2/#4+3 approach where data models are the primary artifacts* if
not -H% artifacts. -his problem results from a combination of the cultural impedance mismatch* a
misguided need to enforce the Lone truthL* and 0normal1 political maneuvering within your organi"ation.
As a result Agile #/As often find that navigating the political waters is an important part of their data
modeling efforts.

3. How to ;ecome ;etter %t Modeling Data
How do you improve your data modeling sills? <ractice* practice* practice. Whenever you get a chance
you should wor closely with Agile #/As* volunteer to model data with them* and as them 9uestions as
the wor progresses. Agile #/As will be following the A5 practice 5odel With 7thers so should welcome
the assistance as well as the 9uestions . one of the best ways to really learn your craft is to have
someone as 0why are you doing it that way1. :ou should be able to learn physical data modeling sills
from Agile #/As* and often logical data modeling sills as well.
>imilarly you should tae the opportunity to wor with the enterprise architects within your organi"ation.
As you saw in Agile %nterprise Architecture they should be taing an active role on your pro,ect*
mentoring your pro,ect team in the enterprise architecture 2if any3* mentoring you in modeling and
architectural sills* and aiding in your team6s modeling and development efforts. 7nce again* volunteer to
wor with them and as 9uestions when you are doing so. %nterprise architects will be able to teach you
conceptual and logical data modeling sills as well as instill an appreciation for enterprise issues.
:ou also need to do some reading. Although this article is a good start it is only a brief introduction. -he
best approach is to simply as the Agile #/As that you wor with what they thin you should read.
14
5y final word of advice is that it is critical for application developers to understand and appreciate the
fundamentals of data modeling. -his is a valuable sill to have and has been since the 1DJ?s. It also
provides a common framewor within which you can wor with Agile #/As* and may even prove to be the
initial sill that enables you to mae a career transition into becoming a full(fledged Agile #/A.

15

You might also like