 Just what is a data model and why is it important? Let's see here. So let me just jump right in. Let's see here. No, I just have to figure out this thing down here. There we go. So, you know, I just want to, maybe it's a little bit humorous, but, you know, get everybody's mind thinking the right way. So if you're anything like me, and you've been working software for quite a while, and you're probably over here where when you're communicating, you're putting messages together, you're thinking more in terms of data structures. Okay, how am I going to organize the data in an efficient way to communicate it and store it? You know, the different concerns that we have in terms of space and time and those kinds of things. And we've been living over here for quite a while. So data modeling isn't exactly that. All right? There is an aspect to it, and at some point we do need to communicate data and need to be concerned with those things, but a lot of what data modeling is, is describing the things that you want to communicate about and how they relate to one another. So really that's what we're getting at over here. It's going to require a little bit of different way of thinking, at least to describe that. So anyway, moving on from that aspect here, what is data architecture? So let's see. I'll start with a textbook definition. And what we're trying to accomplish is to describe the data going into or out of a unit of portability, so your face component that wants to communicate in the context of the entities of concern to the UOP to enable an integrator to combine UOPs together to provide larger capabilities and have a system. So that's all fairly complicated technical speak. So I have a simple English version here. Our intent is to define common terminology so that when we describe communicated data, we know what we're talking about. So we try to keep it as straightforward as that. One way I like to think about this, I like to liken some of this back to a dictionary. The dictionary, super English language, allows us to define certain common words so we can have a common understanding of what those words mean, and we can combine them in different ways to make sentences and talk to one another. I'd say a lot of what we're trying to accomplish, the why in data modeling, is to do the same thing. We have terminology in our domains that we use when we talk to each other. How do we sort of lay that out in a more formal way so that when we build messages and tie the data in our messages back to that, we know what we're talking about? I'd say today we find ourselves in a situation, a preface where we just build messages and count on the name of the field and the message providing all the information everybody needs to know. But if you've done any work on a rather significant program, you know that that's not always the case. Sometimes names are terse, or the author thinks it completely describes what's necessary, but it's not always obvious to the reader. And part of the why in data modeling is to provide that background so you've got more clarity on what the data being communicated is. One thing that I think is important to point out is that data model mechanisms are tended to be domain independent. So FACE doesn't do anything to say that, oh, this is data modeling for mission systems or this is data modeling for communication or flight systems. Practically speaking, you could model just about any concepts that you can imagine using FACE data modeling. So it's pretty flexible, really what you're going to build is something that defines the language in the domain that you're going to work in. So let's see here. Next chart, a little bit of a what on the data architecture. So there's a number of pieces here. Of course, you have the technical standard, which includes what we call the metamodel. And that's really the nuts and bolts of the construction of a data model. The metamodel is sort of the rules on the kinds of things that can be in a model and how they can tie into one another and some additional constraints to think of these as extra rules to add on top. Similar to any kind of programming language, I'd say the metamodel sort of represents a syntax and the OCL constraints are like the semantic rules. In a programming language, it might be a semantic rule that says I've got two variables and I'm going to compare against one another, and the semantic rule says they have to be of the same type. Same kind of idea here. So that's where the definition of the data architecture language lives. Now, there's a couple of other things here that are important to understand. The consortium publishes something called a shared data model. Now, this model has in it some of the real fundamental building blocks that everybody will start with. And if I may continue my dictionary analogy and English words, the shared data model is almost like your alphabet. It defines these real basic building blocks that you can then use to come up with more comprehensive kinds of things. I have another chart that talks a little bit about some of the things that are in there, so I'm not going to spend too much time. There are other kinds of models beyond the shared data model. Let me back up for a second. One other thing, the shared data model is actually managed by the consortium with a governance plan. So you can't just make changes to it. It has to go through a change process. We've got a subcommittee in the data architecture working group that works those changes and publishes the shared data model out of regular intervals. So your UOP will have to be conformant to it and use things in it. And if there's something missing ahead of conformance, you're going to need to work through the PRCR process to make those changes back into shared data model. Now, down below you see other kinds of models here. We've got a domain-specific data model, a UOP-supplied model and an integration model. So if you're building a UOP, the UOP-supplied model is a required artifact. It is going to define your interfaces to your unit of portability and some other items as well. An optional item here is a domain-specific data model. So the idea here being often there's a community of interest that wants to share certain common terminology and definitions. So a lot of that can be captured in this domain-specific model and then reused across a number of UOP-supplied models. So for instance, if a group wanted to get together and have, say, a navigation-based domain-specific data model that defines things like waypoints and flight legs and horizontal protection levels and those kinds of things, that could all be done in a domain-specific data model and then anybody that creates a UOP could use that and you have an agreed-to base set of vocabulary, that's like a little dictionary, that you could use then to design your interfaces in your UOP model. As I mentioned, the UOP model is built by developers of a UOP. It's going to extend you to the shared data model, the domain-specific data model, or both, with things that are not contained there so that everything to be able to use your UOP resides in that model. And finally, there's an introduction to phase 3-0. There's something called an integration model. This is not required, but it does define ways to describe the connectivity between UOPs and some of the key elements of transport services like transformations and aggregations, data marshaling and un-marshaling and those kinds of things, can be described with an integration model. Okay, let's see, there's a lot of detail in this chart and I'm not going to get into all of it, but this is maybe a good starting point for you. I will say that what you see in this chart is not everything that's in the phase meta model. It's designed to give you a flavor of the kinds of things. But what I'd like you to take away is that a phase data model is actually three main levels, the conceptual, the logical, and the platform level. As the name implies, it's the conceptual level. It's where the big ideas live, right? Where you invent terminology. If we were going to invent the idea of a waypoint, it would live in the conceptual model. At this level, you've got entities. So maybe a waypoint is an entity. You can think about it that way. There's also associations. There may be relationships between entities. So if I had a continuing my navigation example, I had a waypoint entity and an aircraft entity. I might have a flying-to relationship between the aircraft and a waypoint entity. So again, just trying to give you a flavor of these things. Another key idea are these observable properties. Entities can have properties. So my waypoint example, a property of a waypoint, might be its position. My flying-to association between a waypoint and an aircraft might have a property of time to go. So there's a time property to it. These observable properties are all things that are defined in the shared data model. You can't invent new ones, not without going through the process. Everything to the left of this line is things that are in the shared data model and standardized across all UOPs for a particular version of faith. Things to the right of the arrow are things that you can define in UOP models or domain models or integration models and so on. Now beyond the conceptual level, there's a logical model. So it takes everything in the conceptual level of the intent being to provide some more detail about how we're going to describe some of those properties. So I talked about a position property. Now at the conceptual level, it's just position, and we all understand that. But to communicate about it, we need something more detailed, like how are you going to give me that position? Is it going to be WGS84, or it's senator of specs, or whatever, right? So that's where some of this gets filled in. We talked about how these properties are measured. And we try to keep it fairly high level. We don't get into data types and things like that. But notionally try to tie it back to systems of measure. That's the main aspect of the logical model is to refine what's here and fill in some of the details, make it a little more specific. And finally, this platform model takes it one step further and actually fills in some of the data types. So using my waypoint example, I may say I've got a waypoint and a position, which has a position. I've got a waypoint, and that position is going to be measured using WGS84, that long altitude kind of measurements. And down here, I've got a waypoint. It's got a position. And it's WGS84. And I'm going to realize the latitude and longitude with doubles and the altitude with an int. So I'll give you an idea on how this stuff all flows. I know I'm going super fast for you guys, but hopefully the message is coming through. And finally, while it's not technically a level, there is a thing called a UOP model within the phase data architecture, which allows you actually to identify a component and describe the data that comes into and out of it. So I can have my portable component and my platform-specific component, which has some number of ports. In each of those ports, users a view element from the platform model to describe what the data is, and it all ties back to your entities and associations. Let's see how am I doing on time. Let's see. One thing I didn't probably pay enough attention to here are views. I described entities and associations, but views are how you actually describe how you're going to take data from those entities and associations and package it up on an interface. So going back to that first slide, where I talked about data structures versus data modeling, the entities and associations are more the data modeling, the abstract side of things, where views are the packaging and how you're going to manage the content of your interface and how is each message going to be organized and those kinds of things. That's where the data structures aspect comes in. Finally right here. All right. Let's see. Let's check the next chart here. So let's see. I've got five minutes left. All right. I thought it might be good to go through a little bit of an example that I hope most of us can relate to based on a university. So I've been using my little waypoint example. This is a little more filled out here. The notation I'm using, basically these rounded rectangles are entities and these hexagonal items are relationships. And this is purely the conceptual level. That's all I'm really going to address here. But again, just to give you a flavor of what kinds of stuff you have to do and put into a data model. So when we talk about a university, some common terms that we're going to bring up, we've got, well, the university itself. There's courses. There's classes. There's rooms. There's teachers. There's students. So how do we capture that all here? So those noun kinds of items, the university, the course and those kinds of things. An easy way to think about it, you can look at those being entities. So the university itself is an entity. And that university, it's got a location. We haven't talked about how we specify it, but universities all have a location. There's courses. And the course may have an ID, course code, something like that. A duration. Maybe it's three credit hours or something like that. It's got a name, something that's a little more human readable. Now, of course, by itself, isn't that really meaningful? It's got to be offered by a university. So there's a relationship between the university and the course, and that the course offers that university. Now, you see I've got some little numbers on some of these things here. Now I'm going to tell you a little about what some of these labels mean. It's course offering, you know, relationship. Well, on one side of it, there's a university. And the other side is the course that's being offered. Now, since there's no numbers over here, it's assumed that each course offering, you know, is part of one university and relates to one course. All right, so if there's no number there, it means one. Now the one to many on this side says, well, a university can play in many, one or more course offering relationships. It basically says that university can offer one or more courses. That's essentially what we're saying here. Paying attention to another part of the model here. You've got courses, which are like things in the catalog, but back in the day when I was in school, there was often a semester, numerous offerings of that one particular course, and there were certain sections of the class. So a class is actually an instance of a course. So any given semester, there'd be a course instance relationships between a course and a class. Angus class is an instance of that course. This course can have one or more instances of it in the semester. Each one of these relationships is between one course and one class. Tracking down this way here. Well, who takes classes? People take classes. And people are enrolled in classes. So here's this class enrollment relationship. It says I've got a class, I've got a person, and there's an enrollment relationship between the two. Now I haven't added anything here to characterize it, but I could put some properties in here if I wanted to further describe that relationship. Now you see here on class enrollments, it's between a class and a person, but in this particular case, we've given that person a certain kind of role name. They're playing the role of student here. If you look on the other side, a class of student isn't really that interesting unless you've got a teacher. So there's also a class teaching relationship between a person and a class. So on one end, we've got the class. On the other end, we've got a person. In this case, we've given them the role name of teacher. So you can kind of see how, hopefully you can see how this ties together. Again, looking at our cardinalities here, this basically says that I can have a person who participates in zero or more teaching relationships. They don't have to be teachers. People don't. In a class teaching relationship, a class and one teacher need that. Every class will participate in one class teaching relationship. So what I'd like to wrap up with on this chart is we've described all these relationships. These aren't data structures. These are relationships between ideas and terms that we would use if we're talking about university. If anybody who understands university can look at this picture and say, yeah, that makes sense. That's what it is. We've defined a ubiquitous language for some small slice of universities. But that's not necessarily how we package up the data. So this little sample view here proposes, I might want to have a message that's got the name and ID of all the courses offered by the university. On phase 3O, what we've done is we've adopted an SQL-like syntax that can be applied to allow us to describe the data that's being extracted from our entity model. So here I'm going to say let's course ID in course name. I said I want the name and the ID of all courses. From the university, if you're familiar with SQL, I've just given it an alias called U so I can take myself a little typing. I'm going to join U University on this university line to course offering. So course offering, this line is labeled university. So I join it from the university to course offering and from course offering on course to course. So I get from here all the way over to here. And again, I selected the name and the ID and this describes a view that contains all of the course IDs and names of all the courses part of the course offering relationship with the university. You know what I haven't described here is how we package that up, but that would be a little deep to get into for this quick session today. But there's a template and mechanism that allows me to take this data now and format it into a message that's the data structure I'm at when I communicate. So let's see, that's the last slide I plan on going over. And I think schedule-wise, we're just over 20 minutes. So what's the next time? And do I... That's great, Bill. Thank you for that. Judy, do you want to say a quick word? Sure. My name is Judy Serendia. I'm from the Open Group. I'm the faith consortium program director. And I do want to thank our presenter, Bill Kinahan. He's a chair of the data architecture working group within the faith consortium. Works for Sikorsky Aircraft, so deeply entrenched in the avionics software development that we focus on. I also want to thank all of our attendees today for joining. Hopefully you learned a little bit more about the faith data architecture and some details from Bill's examples on how to construct. Data architecture or data model concepts. If you need any more information about the faith consortium, you can check us out at www.opengroup.org or gslashface. And if you have any particular questions about today's webinar or just want to get additional information that's not available on our website, you can contact us via email at ogface-admin at opengroup.us. I thank you again for joining us. Enjoy the rest of your day. Take care.