 I'm going to talk about the UML, but I'm actually a database person, so hopefully I didn't scare you with UML in the title, so I got to get all the mechanics of this stuff right. So what's the UML? I'm sure most of the people in the room here have heard what the UML is. UML is unified modeling language, you know, I mean that's a little presumptuous right there, but it's a graphical language from modeling software, and it arose from the many object-oriented software development approaches of the 1990s, that was a good thing, because in the 1990s there's this tower of babble effect where there's different notations, different methodologies around, they're all trying to do the same thing, it's not constructive, and the purpose of UML was to try to standardize that, which is a good thing, there's some good things and some bad things about it, I'll try to talk about both, and it's been sponsored by the object management group. So UML has a variety of diagrams, I don't know if there's a diagram, I think in general it's hard to think of a diagram they didn't throw in the thing, there's so many different diagrams in it, so I just list six possibilities there, the class diagram is really the UML model for data modeling, so that's what I'm going to talk about here, but they have object diagrams, use case diagrams, state diagrams, activity diagrams, sequence diagrams, collaboration diagrams, I mean all kinds of diagrams, I'm not going to talk about that, I'm just going to focus on the class diagram, so what is UML good for, more specifically what is UML good for with regard to databases, I'm not going to talk about all the other models, so UML class model is good for conceptual data models, I use it for that all the time, I use it for communicating with business experts, and so this slide is going to talk what's good about, the next slide is going to talk about what's bad about it, so I use it for communicating with business experts, and it's good because it defers database details, I don't have to talk about primary keys and foreign keys and alternate keys and candidate keys and indices and referential integrity and have their eyes glazed over, I can focus on the key entity types or classes and the relationships between them and the critical attributes and have the discussion at that level, so I think I don't know where I read it, I read something recently where somebody was saying oh you can't show UML model to a business person and well there's all kinds of diagrams, so if you're talking about some of the other diagrams that might very well be true, but as far as the class model is concerned I show it to business people all the time and actually what I do is I get my laptop out, I project it on the screen, I get 10, 15, 20 business people in the room from all different camps and we'll just start modeling and they'll, oftentimes it's like kicking off an application model, so they'll start communicating requirements, I'll start capturing them as we talk and they have their side business discussions and we just proceed and actually works quite well with that and when I first started out doing it, I kind of had a preamble where I explained UML terminology and concepts and notation and I attended a talk once at a conference and this guy didn't even have the introduction for his talk, he just launched right into his material and I was quite impressed with that, so I said let's try doing a UML model, I'm not even going to explain it to him, I just got launched right into it and that actually works because I mean the UML class model is derived from Peter Chen's entity relationship notation, it's quite intuitive, there's not that many constructs to it and I keep translating the model back and forth into English as we go, so you don't have to understand precisely what all the constructs mean because they hear me explaining it in their terms and they ask questions, I answer the questions, we go back and forth, it actually works quite well and I actually have a demo of doing that on YouTube and I got the link for YouTube on my last slide if you have any interest in that, so another thing the UML is good for is obviously communicating with programmers and there's a lot of programers grumble about the UML but they're familiar with it and they use it nonetheless so you can reach them, one of the things I really like using UML for is abstraction and thinking abstractly about data models and data modeling patterns and it's really helpful when you're trying to think of how do I abstract the model, what level of abstraction am I at, what do I exactly, what's the trade-offs and representations and not have to deal with keys and identity and all that and set that aside as a later decision so UML is good at that and another thing UML is good for which some data people may not pay enough attention to is you can summarize behavior in the UML model and that's quite useful and I can give you at least three examples of where it's useful, one is say you got your high-level conceptual model, your classes, your entity types are representing the business terminology because there's no reason you can't fit the high level methods, high-level operations on the diagram, that's just like the service-oriented architecture mentality when I put them on the diagram so that's useful to communicate, I do that sometimes, it's useful to communicate there, another reason for putting behavior together with data model diagrams, the database people care about is a lot of applications of stored procedures and it's useful to put the stored procedures with the data and think about it that way and the third reason is I'm working on this, I only have partial progress, I've been using data models to try to drive the design of XSD files and XSD and XML is data just like databases and I think it makes sense to drive that off data models too and if you're dealing with XSD and XML files oftentimes you're dealing with the service-oriented architectures so why did I put the summary of the services on the same diagram? So having being able to summarize high-level behavior and the data modeling diagram is quite useful in practice so what are some uml weaknesses? Well, uml does not address database design some of the uml tools out there do address database design like enterprise architect, I don't use it for that I mean they do support database design I've had some discussion with the vendor they've shown me some of the things they do other people I've seen them use it for that I don't use it for that I find it more convenient if I'm doing a database design or they use Erwin or a tool like that for database designs so actually the way I often operate is I use a uml tool for the high-level conceptual model and I transition to a database tool like Erwin some were around the logical model so I often use a blend of the tools together but like I said there are some uml tools I do address database design my personal opinion I think they're clumsy another one of the uml weaknesses is over-emphasizes programming jargon actually from a database point of view it's offensive I mean it's just right in your face you can hardly get away from it I never got involved in the I never got involved in the omg process for creating the uml I could have gotten involved if I want to when I was a GE research I worked with Jim Rumbaus I knew him quite well and I could have used that as a non-trader to get involved with the process I didn't want to do that I mean one of the reasons I became a consultant is I could do what I wanted and that was one of the worst forms of torture I could think of is to be involved in that committee so I didn't want to do that but you know I heard things about the object management group meetings even though I wasn't there from other people and it's just all this programming minutiae was driving it and and actually the work we did at GE was one of the inputs into the uml and when we did a work at GE we paid attention to databases so like the omg the good thing they did is they got rid of this tower of babble with these different notations that meant similar things when the bad things they did is they lost the database input but you know I talked to Rumbaus about some and he just told me there's so much politicking and and negotiations and so forth you could hardly get the people there to pay attention to databases so that's just what happened another uml weakness most of what I see I see most database practitioners especially those with some level of skill they're aware of the uml they know what it is maybe the beginners and novices don't know what it is but the serious practitioners they know what the uml is but not many people use it in practice that's what I see I'm a consultant I go in and out of a lot of companies so I actually see quite a bit and there's certainly a chasm between the programming and the database cultures between the style and the chasm's artificial a lot of it but it's there and nonetheless so the weakness of uml is that it's not widely adopted I actually think it can be used more widely and that's part of what I'm trying that's what I'm advocating in this talk and of course uml is not relevant for data warehouses and just to be clear and one of my past books I wrote about 10 years ago I have a star schema and I did a uml model for it and that's not incorrect but I would say now it's pointless why bother using a uml model for a star schema the structure is so simple you hardly have to try that and you're not going to abstract any further it's already abstracted with the star schema and and when you're looking at a star schema database you often will see the keys anyhow so why suppress that so it's not wrong to use uml for that like I did in the past but I don't think there's any purpose to it so what I'm going to do is I'm going to walk through a number of uml constructs and explain them with examples and some commentary and I'm going to try to compare it to IE as I go and I've done this before and it actually went over quite well because people have been using IE models I mean over and over again and know the notation inside out and it's a good anchor point for explaining uml stuff the diagrams I'm going to show here for the uml side use enterprise architect and for the IE side I used Erwin Erwin is iDef 1x and IE there's a switch yeah and actually I use iDef 1x most of the time with Erwin and I actually use that in the prior version of this talk and I would I give it to Chicago Dame the last fall of prior version of this talk and I kind of solicited commentary from the audience and one of the comments I got from the audience that I didn't know before is this lady said if you use iDef 1x I'm not going to pay attention to you I want to see iE that's all I use no it's fine I asked for comments that was a good comment I appreciate it and uh so my so I have two thoughts in my head and she said IE is what everybody uses so I got two thoughts in my head one is she doesn't know what she's talking about or the second comment is she's right and I don't know which one's the case so I actually talked to a lady a computer association she said hey it is widely used she's this lady's right so I switched IE for this talk I actually worked with logic methodology that Erwin uses what you're seeing when you switch okay is the notation it gives you the ability to change the notation but all the methodology rules that follows when you're in IE if I get through any other comments or questions before I proceed okay so here's an example of a uml data model um hopefully it's well I hopefully it's somewhat readable in the back I'll uh I'm going to go through pieces of it as I proceed so here's an example I'm not going to walk through it's a frequent flyer a simple model for frequent flyer information I'll go through pieces of it as I proceed I may come back to the slide here's the exact same thing in IE notation and this example doesn't bring it out real well well there's a couple of comments I'll make so first of all if you look at the uml data model the boxes on that and the boxes on the IE model closely correspond not exactly correspond closely correspond and the second comment I'll make about this that this example doesn't bring out as well as others is generally speaking the uml data model has fewer strings on it fewer text legends on it than the IE does because you're not showing all the keys for example so it's more compact it's more concise it's easier to explain at a high level having a smaller model does matter if you're interacting with a group of people in the room you can fit more in the screen it's more legible when I when I do data modeling I'll often split things across subject areas that confounds a lot of people because I want to see it all on the screen so being able to have a higher information density without just shrinking all the fonts that is useful so first concept is a notion of a uml class and that's the same thing as an entity type in IE and here's just a very simple example and you can see the so I define what an object is what a class is so an object's a concept abstraction or thing with identity and application meaning so even in the UM when I'm doing uml model I don't show primary keys I don't show um I don't show foreign keys as such I do I'm thinking in terms of identity I think of that all the time and then the class is a description of similar objects so object corresponds to entity and class corresponds to entity type and you can see the uml notation to the left and the IE notation to the right for the same thing okay yeah so customer is an entity type uh entity is John Doe, Jane Smith and a lot of the the literature is really sloppy on the term entity um so that's actually a good question for thank you for the question the literature is really sloppy so that's why I use entity entity type uh the correspondence between those two words is clear but if you look at entity in the literature sometimes we're referring to an occurrence sometimes we're referring to a description uh literature is inconsistent and I avoided the word instance um that sounds like a programming term to me that's a prominent term in uml and um I'm trying to avoid gratuitous programming jargon so I deliberately avoided the word instance I'd rather use word occurrence entity type is like a customer entity is like Jane Doe, Jim Smith you know so an entity type is what you type into a Irwin model an entity is a record on the table so uml attribute this prior slide shows classes and attributes frequent flyer account is the name of the class and the three items underneath it are attributes account start date balance current amount and balance current date so a value is a piece of data for an object and the attribute is a description of similar values so in the case of uml the notion of value and attribute has the same meaning is what you'd expect from the database world that's the same um and like I said the prior slide shows a few attributes and then the so actually the uml box is three parts I only showed two the top has the class name the second has the attributes and the third has the operations so I just didn't show it in my example but the operations are behavior for an object and I got a really simple example here like you could compute the current balance and retirement activity posts have been examples and operations derived data and earlier I gave you some um some methodology reasons why operations are relevant to data models for example like I said you can you can summarize services you can represent stored procedures and sometimes in my data models I show operations it's quite helpful okay so here's another uml term the notion of an association association is a uml term I think relationship is generally what I see in the database world and here again is a simple example uh frequent fire the customer has a one to many relationship um and like I said the uml model has the same meaning as the ie model on the right side so let me uh define a couple concepts I want to come back to this model so link is a physical or conceptual connection among objects it's at the occurrence level it's record level and an association is a description of similar links so that's at the type level so entity type class association are all the same thing object link occurrence are at the same level so I disagree with your statement a couple ways so yeah if you look at if you look at a lot of the object-oriented literature yeah they're talking about object-oriented design yeah that's what they're talking about but uml intrinsically it's not tied to object-oriented design I use it all the time for object-oriented analysis and actually where I came from a GE research I mean we wrote a book that was one of the methodologies that was a pre-course uml a few of you here might have heard of OMT object modeling technique is what vaunted rumba to the limelight as a co-author of their book the focus of the book was an object-oriented analysis object-oriented design was like a secondary thought was an afterthought in their book one okay and like I said so we're talking about object-oriented analysis butch was talking about object-oriented design with the uml is certainly as people can explain it and convey it the design aspect is emphasized but still the uml notation intrinsically is not tied to design and then the second point is what's in the uml notation what's in the tools are two different things and uml tools are really emphasizing design too and in my view that's unfortunate you got this junk you got to look past use them and yet you actually pointed that really well Dave in your book you really pointed that out well I've kind of yeah I use uml and I've just I've just kind of like subconsciously look past all the junk and focus on the core notation when you actually can't turn a lot of it off you gotta ignore it and uh and it's it's offensive from a data modeling point of view so so there's a lot of baggage with the uml which certainly represents which certainly tilts heavily towards object-oriented design which tilts for its programming design not data design there's a lot of baggage with uml like that but the core language is an ER notation you can use it like that and that's what I do and I've defined it accorded accordingly so but like I said and and and and like I said in your book you made a very I thought you made a very good observation uh about all this baggage with the uml and uh I never paid that much attention to it I've always kind of wondered why don't people use it more it seems kind of obvious to me well that's is one of the reasons so I think it's a good observation any other questions okay so um so I talked about link and association it's the same link is the same as a relationship association is the same thing as a relationship type the word relationships use ambiguously just like the word entity is the type or occurrence level so I guess if you really want to be careful in the database literature you'd use relationship instance relationship type and avoid the word relationship so but so looking at this example again in the IE notation you can see that I didn't put a name on the relationship I'm sure most data modelers would probably do that I often don't bother okay enough that's um yeah that's right so you can see my bias there you can see my bias there and um that's certainly a matter of style when I um go well if it's a many to many relationship and I go to implement the relationship of course with the table I pay attention to the name then so I'd be more likely to name those um I've won the many like this I'd be more likely to name the customer end especially if there's multiple relationships the customer and I want to disambiguate them so that's like a rule name I'll talk about that coming up but like I said I'm just calling attention to the fact I don't I don't have a relationship name on the IE and some people might object to that and on the UML it's certainly fine not to have a relationship name uh it's common I would actually make the argument that the N names are more fundamental than the relationship name another comment I make is on the IE often when there's relationship names or directed names you have to read them one way here's one name you gotta read the other name here's the other name and actually the origins of the UML we didn't have directed relationship names because from a semantic point of view there's no point to that other than the fact that words happen to read one way or the other I mean just really semantically there's no point to it well in the UML of course there's directed relationship names because point because programmers think of implementing them with pointers so but that's not what I'm calling attention to here so I showed a binary association that has two ends and each end can have a name and a multiplicity sometimes it's called an association N name sometimes it's called a roll name officially now in the UML I think it's called an association N name I think they couldn't think of a longer name for it than that so that's why they use that so it's just a legend next next to the intersection and I use N names a lot because oftentimes we have a we have a primary key that's referred to by foreign key you rename the foreign key and the roll names are really nice in that regard so yeah okay so I don't have any other examples of that oh and another point I'd like to make let's see yeah multiplicity so multiplicity is a number of instances of one class that may refer to a single instance of an associated class so actually in the UML word people use the term multiplicity which is actually the correct term in the database world people use cardinality and they're being sloppy it's a wrong term so cardinality is the size of a set multiplicity is a constraint on the size of a set so multiplicity is what you are doing in the database world cardinality is a sloppy name that that just about everybody uses to refer to the same thing and the reason I'm so aware of that distinction is I wrote a paper in the past I must add a mathematician or reviewer or something he corrected me and educated me and fine okay fair enough but like and so like I said in the actually in this regard the UML has it right and the database world doesn't have it so well so but like in a lot of times I use word multiplicity seems to confuse database people but like I said loosely speaking it's the same as cardinality so oh here's an example of an association class so that's kind of to the left side that's more foreign notation to most database modeling people there's a many to many relationship between airline partnership and airline for example there's a star alliance that's an airline partnership and united's an airline that belongs to the star alliance Lufthansa is an airline that belongs to the star alliance and you know when they go in and out of the partnership you can have effective dates that can consider good form that's now analysis model because the model means that already why you need to say it again what the model says to the left is a combination of an airline partnership and an airline uniquely identifies let's see if I can get this wasn't so good was it okay there we go that stupid little red pointer airline partnership and airline the combination uniquely identifies that that's what the model says you need to say it again so like I said this is an analysis level model it's a conceptual so when you do in the uml model when you do conceptual models you can certainly do in the uml if you do full-fledged logical models for a database well you probably won't bother doing that uml when I use a database design tool but if you use the conceptual model with some of the critical attributes you can certainly do that still in the uml and at that level why do you want to clutter it with something that's already stated and this model on the left this model on the right meet exactly the same thing mm-hmm yeah like I said I'm I'm no no let me continue let me continue so so yeah I do write definitions like I said I'm actually a database person if I I do programming many years ago I don't do it anymore because there's a waste of my time I rather do the database stuff so I'm actually a programming person who's into object-oriented methodology I don't mess around with java and c plus plus and all that stuff I'm just on the methodology side so when I define these things I do it a couple ways one way is a dad dictionary uh you in a tool like enterprise architect you can click on a class and attribute pull up a panel and type in a definition just like you do in Erwin same kind of thing so do dad dictionaries I um for business people often have narratives where I'd have a word documented I copy and paste the uh the model and then I write pros where the definitions are embedded in so yeah of course I define things okay oh hi okay okay so okay so there's there's two comments here that's a good point there's two comments here the first the question I had here earlier is putting the foreign keys in the association class I said that's unnecessary okay I misunderstood I misunderstood okay okay I misunderstood then I misunderstood okay that's fine okay so that was a misunderstanding so so in the uml you can name that or not name it and both are correct and this is small model so I didn't bother to name it and what I and what I do when I'm doing a database design I'd call it like airline partnership underscore airline um so yeah so in the uml model if you want to say hey that's not a good practice I can't find the thing which is actually a fair comment because if you're like an enterprise architect a tool and you look in their browser window it's not named you can't tell what's what but if you go in the diagram and click and say jump tooth in the diagram then you find it so if you want to say as part of software engineering protocol you always name them that's certainly reasonable enough I often don't do that but you might actually be a good idea to even do it all the time that's fair enough that's fair enough that's a good point happens to be many to many you can't represent that in sql or in a relational model therefore you have to convert your relationship into an association entity and all entities have to have a name that's how you get to that point but the point is also the gentleman back there and the gentleman up here making the point that in the tool also it's a little cumbersome if you don't have names you got to play tool games um which is like I said there's certainly nothing wrong with assigning a name to that if you choose do we want to talk about it now because you can address uh go ahead if you got question if we run on too long I'll move things ahead so I mean in the entity relationship world every entity must have some mechanism of uniquely identifying an instance in the uml world you can if you so desire although you you know developers probably don't like it you can list for example uh uh in airline you could have airline id there as a as a nah nah that's a good form uml you don't show artificial keys that's not a conceptual model every object has intrinsic identity you take it for granted when you're doing the uml the database side you show what the identifier is explicitly so but okay yes and then uml you could say it but the uml actually doesn't address that you gotta do some ad hoc right which is ad hoc okay no actually let's Dave say some but still the right but in an analysis model you're not supposed to show artificial things and that was my point but I'll make another point here is uh you notice in the i.e. model I made airline id the primary key could have made airline name the primary key um and you know that's a trivial example but in a real in big models you have this stuff all over the place so the uml model actually corresponds to multiple i.e. models depending on how you go about doing identity how you go by doing primary keys so uh and actually if you're thinking about when you're doing a conceptual model you'd really rather not be dealing with that you really like to defer that decision the whole idea of software engineering you defer decisions till you have to make them so virtue of the uml model like this for conceptual modeling is you don't show the identifiers and of course any kind of reasonable database design any kind of intelligent database designer is going to address it at some point and usually I have guidelines and rules and so I always use id's for identifiers I know it's a religious argument whether or not to do that I'm in the camp of always using id's but regardless deferring that and not showing it in the conceptual model is a good thing and business people greatly appreciate that just brief I want to move on yeah well I accept yeah it's a logical model but corresponds to uml and I'm trying to show the correspondence is why I did that because people are grounded in i.e. and not grounded uml and I find out I have discussions with people and they say uml means this I said no it doesn't mean this the same as i.e. it's like oh and that's kind of I found this kind of a useful way to try to communicate and I actually think in both worlds so I mean this is the way my mind operates so so let me talk about qualified association that's something that's unusual in the uml that's not in too many database modeling notations but I think it's a really good idea so if I want to find a frequent flyer account the airline plus the account number yield to frequent flyer account of course an airline has many frequent flyer accounts the account number disambiguates them so it's not I'm still not saying what the primary key is this is a semantic statement I'm saying that the frequent flyer account is the natural key to that is the airline identifier plus the account number I'm making it's a constraint it's a it's a semantic statement of constraint and this i.e. model is a corresponding model to uml model so so I use I use qualifiers quite a bit so when I do data models I pay lots of attention to natural keys because they're important constraints on identity but I I rarely use them as a primary key and I enforce them separately I define as alternate keys so um so that's the uml qualifier I kind of explained that so here's an example of uml generalization I guess this corresponds pretty well to the database world there's not too much difference there so the uml models on the left and the i.e. models on the right and the uml model on the left actually it could have showed the activity discriminator there too enterprise architectural will certainly display that they don't call it discriminator in the uml notation in the uml jargon it's it's generalization set name so I don't I'm not especially fond of that so I use the word discriminator but you know they mean the same thing and that's the point and you can go in a uml tool such as enterprise architect and assign an activity discriminator to it and show it just like in the right model even though I didn't do it here so another comment I'll make is uh Dave's comment I took him like a month fumbled around with the uml tool and come up to speed I had the same kinds of problems uh yeah I mean I could construct a simple diagram very quickly but to become skilled at the tool and get the thing to do what I wanted to do it took me a while to come up to speed and that's part of the reason I decided for database design I'm tired of fighting it I'm not going to fight it for that and then the other thing is too if you're using a uml for for data modeling you're outside the mainstream at some point you got cut over to the mainstream and and that's another reason why I use a tool tool strategy so whether it's exhaustive or not overlapping okay overlapping's the term oh geez I I know I I know the the object going modeling literature addresses whether it's exhaustive or not whether it's overlapping or not I don't remember off hand exactly what they have in uml 2 and what they don't so they they address it I'm not sure exactly what the notation is what I always do is a matter of software engineering protocols I never use overlapping uh and I also use all we use use exhaustive and if it's not exhaustive well there's another subtype you know so I uh well that's my mistake on the slide yeah yeah yeah I see it now I see it now that's my no it's my mistake on the slide okay yeah yeah because I'm actually starting to write a book now and some of the stuff and I fixed it in the book and I it's a mistake on the slide I intended the x so I'll make some more comments along the same line so when I'm doing data modeling I never use multiple inheritance doesn't happen that often I confuse business people it's easy enough to work around when I get into design and if I'm happening to deal with an object oriented language I might use multiple inheritance because you can mix in different aspects but I avoid it when I'm doing conceptual modeling therefore I don't have overlapping that's a formal multiple inheritance I just stay away from it I recast the model to avoid it so that's uh one of the few examples when I'll take a conceptual model and maybe tainted a bit looking ahead towards implementation I just don't I just don't want to deal with it I want to explain it because you're going to confuse the business people in practice it doesn't happen that much it's not worth the headache that's my opinion well actually I've maybe I'm incorrect on this I've treated both these forms of multiple inheritance in the past so maybe that sloppy jargon but fair enough what's that right well yeah we agree on that so so you can certainly see even we're here talking about here and it's a little confusing to talk about so boy I don't want to do that to a business person that's not a very nice thing to do I mean they're ready tolerating me being in the room as it is so oh here I got a few comments on Dave's new book I've read it it's a very good book I agree with some things don't disagree with some things not surprising it doesn't necessarily mean I'm right even but points of agreement Dave says the umel was not designed with databases in mind well yeah it's like yeah it's like it's not and there's program and everybody knows that that's pretty what he said that nicely and it also is programming oriented details it should be ignored and I've actually never said that in my writings and I should so that's actually a very good observation sometimes you have these biases or assumptions that come in your head and you don't state them and they're not helpful to people and that's something that Dave pointed out very well that I actually haven't in the past and I'm correcting in the future we don't agree some in terms of associate umel roles and relationships I'm not going to try to say here he's wrong and I'm right I just say we don't agree so and I actually like to talk about that some offline we get a chance um okay so you oh you don't cover some umel I read your book that's fine that's fine and and I and if I was going to do the slide now I wouldn't use that word so I I'll accept that correction and then I'm not uh you you're you're you're you're you're thought to very okay you know what I don't agree with that but go on the issues that I thought you actually said specifically in the slide the umel inmate is an alien for black yeah that's right that's right I use it for that correct but we both agree that misunderstands is not the proper word here and and I accept the correction which is fair enough um so using umel and IE together so um I use umel for the front end of the modeling the conceptual and some of the logical modeling and then I use IE I've used all kinds of notations over the years I use IE or something else if that's what the customer wants for the database design which is the full floods logical and the physical models for data warehouse applications umel's pedantic why bother then another comment I'll make here is one of the things that I like about the umel is um is actually I I look at a umel model and I traverse it and I know how the umel model corresponds to sequel code because I have mechanical mapping rules I use so I look at a umel model and I think in terms of traversal and actually write sequel code that does that um so traversal umel model and sequel code is the same thing to me uh it's just like it just interjoins in sequel so uh you know of course you got complex sequel queries like nested queries and that that doesn't correspond directly umel but you know a lot of the a lot of the boilerplate and sequel queries is just interjoins and conditions in the where clause and selection of columns in the select clause so I think it's really useful to think in terms of traversals when you look at umel models and I emphasize that with business audiences and that's one of the ways I try to get them to internalize it and check the model to make sure it works because I say if they got a business query and they can't reverse the model to answer it and all likelihood the model's broken we got to fix it and here this is this is I'm sure you remember this this string here but I got some videos that show how I use umel models with a business audience as dummied up but it's representative say that again please I don't know what you word but I don't know what you meant by the word extend oh the way to the front there extends now the defined term that's what I'm objecting to okay fine of course of course yeah super type yeah umel activities are super class flight activity and other activity or subclasses and it directly corresponds to this IE model activities are super type and flight activity and other activity or subtypes I don't understand the point that's right okay so one of the things I'll do sometimes the implementation I'll define two views on top of this so the generalization partitions the objects but for I can define a flight activity view which pulls in all the activity attributes and all this and I can define another activity view which pulls in all these the fundamental problem is as follows object going languages have intrinsic support for generalization a relational database does not so you have some kind of a workaround this is usually what I do is three tables but yeah some people sometimes they shove it all up here sometimes they take the attributes and copy it down here but if you got complex topology that doesn't work so well right so there's a little bit of bias but like I said if you got a complex topology this is the default way that I that I always do it and most other people do it this way that I've seen too so that's all that I got thank you for attending I'm happy to talk to anybody offline