Geodatabase Design

as we move into doing more project-based work in the class it's important to to broach the concept of geodatabase design this is working to find the best representation in your computer of the real world geography that you're trying to to build a GIS around geographies complicated we have many different layers that we need to create to represent the real world around us these layers can be related to each other they can be made up of points lines and polygons they can have additional more complex structures built on top of these points lines and polygons like utility networks or transportation networks topologies surfaces and other information this representation shows the layers used to represent the real world and the attributes that are part of those layers in arcgis we can represent geography in a number of ways the simplest ways are the points lines and polygons that we've been seeing this semester as mentioned you can also have additional constructs on top of these simple feature types like networks and topologies we can also represent geography through continuous surfaces raster based data and things like locations that can be represented by addresses or a set of coordinates these geodatabase elements should be familiar to you at this point we can have non-spatial tables in our geo databases we can have feature classes of points lines and polygons as well as additional annotations dimensions and routes these may be organized in featured data sets we can also have things like geometric networks Network datasets terrains topologies survey data sets and a whole host of other things these geo database elements can have behaviors defined by attribute domains and topology rules to mention a couple so the purpose of geodatabase design and the goals of geodatabase design are important to understand in order for GIS to be effectively implemented you really need a good database design to start asking the appropriate questions is key to building a database that will support your organization your needs and your goals questions like who will be using the database and how they'll be using it if it will be shared the different people or departments responsible for maintaining the database or parts of the database and what kind of business processes will the database support you the design process is where these goals are defined you look at design alternatives and make sure that you have options if your design doesn't support your needs and you agree on an implementation plan to implement your database design essentially you're deciding where you are where you're going and how you're going to get from one place to the other so a functional and well-organized database and does the following it satisfies objectives and supports organizational requirements it contains all the data of the organization but does not have redundant data it organizes data so that different users can access the same data it may accommodate different views of the data like streams maybe line features at a small scale showing a large area but if you zoom in to the city of Asheville the River French Broad River may become a polygon feature class it's distinguished applications that maintain data from those that use it you may have a web server an Internet map site publishing the data and providing some kind of application to use the data for an end user whereas you use ArcGIS desktop to edit and maintain the data you can appropriately represent codes approp appropriate representations codes and organizing geographic features as another objective objective of your design so design takes time it is very important to spend the time upfront it's a pay me now or pay me later kind of thing if you don't spend the time upfront to design your database once you build it it may not support your business needs so you'll have to go back to the drawing board and redesign and you'll spend more time and money doing that if you don't design them your database may not meet the requirements that's to support things like mapping and editing and analysis you might have duplicate data or missing data and there may be a lack of necessary management and maintenance techniques to keep the database up-to-date and usable so here are some guidelines to think about it's an iterative process you need to get a bunch of stakeholders or users involved in the process you take it one step at a time you get all the users in a meeting or multiple meetings you come up with what they think they need in the database and you start to build it and then you come back to them and ask them if what you've done is is what they were thinking so it you it's an iterative process you want to be creative and create deliverables make sure your organizational goals and objectives or in focus you don't want to start adding data to prematurely you want to make sure that the structure or what we refer to as the database schema is built and ready for the data before you start adding it to it make sure to document what you do be flexible plan from your model and pilot your design piloting your design in a small area will allow you to go back to the users and again continue with that iterative process to make sure the database supports the organization's needs and this represents the database schema so again the database schema is the structure or design of your database not the contents of your database so in this clay cat case you're looking at a database design generated from a unified modeling language tool like Visio Visio and other UML tools or tools that allow you to design and model a system and you can design a model databases with them very effectively so this shows all of the future glasses their relationships with each other the attribute fields that are stored with each feature class this is the state boundaries feature class you can see it is a line feature class geometry polyline it has a set a field for each one of those fields there is a type of data that can be stored in the fields some of them have domains and other information so you can see this document very details every feature class their attributes attribute types spatial references domain subtypes topologies all that kind of information here's the domain here so this is the schema of the database you want to determine all this information before you start adding data make sure you know at least the feature classes that will be in your database or the layers the feature classes geometry whether it's going to be a point line or polygon what attributes each feature class will have and domains that will be part of the attributes and how these feature glasses relate to other feature glasses and if they'll be used to build an additional construct like a network or a topology in addition to the simple feature glasses also think about how you'll organize your feature glasses into feature datasets a jury has a lot of industry specific data model templates they're a great starting point - for your database design you can see them there and I've got an example in the next page if you went to work for a sewer district and they said design me a new database the best thing for you to do would be to start with an existing database that was already designed this is the database schema in a UML model from the ArcGIS sewer stormwater data model you can download the structure the schema the shell of the geo database right from ESRI and start importing your data into it that's not really the best practice with these kind of data models they are built to support many different storm sewer sewer and stormwater organizations across the country so an individual one would there's far too much data in most of these data models but they're a good starting point so here are the design phases these are kind of big broad design phases there's the conceptual model that's when you're just talking with stakeholders and identifying the different kind of layers and tables and attributes and things that will be done with the database then the logical model is when you map your layers that you discussed to actual geo database elements things like a point feature class or a or a geometric network once you map out everything you discuss with your stakeholders in your logical model you can create the physical model actually build the schema so just a little graphic that shows these steps from your your conceptual model where you're just talking about the layers and the attributes and the tables to mapping them to geo database elements like feature classes and topologies and networks and then you're building the schema in the physical this came out of a geodatabase design but that that outlines the steps of building a geodatabase and from the these five steps as a part of the conceptual design and the launch were design the conceptual design is modeling the user's view and defining entities and relationships as well as identifying representations of entities points lines or polygons the logical design matching to geo database models and different elements that are available to you in the geo database as well as organizing into different geographic data sets the more recent ESRI documentation lists these 11 steps to geo database design and they're a little bit more detailed and I think they're a good reference to go by you can see these using the as the link in Moodle this is available on the ArcGIS desktop resources page and this shows you these design steps so we'll talk about each one but I'd like for you two to read about these as part of your required reading this week so the first step is to identify the information products that you will create and manage with your GIS your GIS database design should reflect the work of your organization so make sure to consider what your organization does their current workflows and processes and identify how these workflows and processes will be part of your new database and make sure that they're supported step two is to identify the key data themes based on your information requirements so here you define more completely some of the key aspects of each data thing determining how each data set will be used if it's for editing or analysis routing specify where the map data comes from what maps will be made all this kind of information from there step three you have to think about the scale ranges and spatial representations of each data theme at each scale so are you gonna model cities as points or are you gonna model cities as polygons so as scale changes the representation of our data often changes as well so make sure you understand how you're gonna model each feature class and if this representation will change based on scale you may have things represented at different scales in different ways also think about raster data and how you're gonna represent raster data whether it will be in a in a mosaic data set whether you're gonna build pyramids how you're going to handle your different data at different scales step four is decomposing each representation into one or more Geographic data sets so these discrete features can be modeled as feature glasses of points lines and polygons you need to consider if you're going to have advanced data types like topologies and networks and terrains and decide how things are gonna be modeled and feature datasets how you're going to model your raster data and really start to build this into the actual constructs available to you in the geo database data model Step five is to define the tabular database structure and the behavior for descriptive attributes so this is when you come up with all of the attributes that will be stored with your with your layers an example would be if I wanted to create a point of interest layer for the national forests what kind of attributes am I going to store for these points of interest how about the name of the point of interest the type of the point of interest may be a description of the point of interest so that's starting to define the attribute field but you also need to define all of the possible values for those attributes for instance the type field what kind of types of points of interest are there on a national forest so for the type attribute field I'm going to store text and the types of point of interest might be a fishing location or a picnic area or a campsite or a ranger station all of these could be put into a domain or drop-down list for points of interest but the point is not only do you need to think about what attribute field you're going to store but also the values you're going to store for that attribute from there you define the spatial behavior or spatial relationships and integrity rules number six for features you can add spatial behavior and capabilities and also characterize spatial relationships inherent in your related features for for purposes such as using topologies and networks so you want to think about any kind of topology rules or networks that you want to build any advanced functionality from there you've proposed your geo database design so you come up with a set of geo database elements you want in your design for each data theme you look it patterns and best practices from other database designs like the ESRI data models step 8 is designing and editing workflows and map display properties you want to think about the editing procedures and integrity rules make sure that you've got a set of processes in place for the person editing and maintaining the data as well as how you're gonna map it and how it will be used for mapping and analysis you want to then assign responsibilities for building and maintaining each layer who's gonna build populate maintain the database build a working prototype review and refine your design and then of course document your geo database design documenting your geo database design is very important and there's many ways to do it this is called a database design document and it is the most accessible to people it's easy to use it's essentially a word document where you have the feature class name you have a description and then a table that shows attributes attribute types and domains it also lists the subtypes with this particular layer relationships topologies so it puts everything in one document related to a layer there's also classic lair diagrams and they organize data into logical units they focus on common data elements to help us determine things like attributes associations and spatial relationships you can see this part of this diagram is referring to a topology feature class and it has all of these layers that participate in it it shows that the ranks and the rules you can also use unified modeling language is like Visio these are good for large designs some database elements geo database elements may not be supported these are used for for database design and in all kinds of industries outside of that the GIS world this is an example of one for to use something like this you do need a unified modeling language program like Microsoft Visio there is the Geo database diagram er that uses Visio to create edit and analyze geo database scheme you can learn more about it here but know that it's really best for large designs and you do need Visio to uh to do it to use it so from there how do you construct the database you can create schema with some different wizards and arccatalog if you have a database structure someone could export it to XML and then you can import it using our catalog from there you import data or you can import data importing data creates structure similar to that of those imported you can use schema tools and also the ArcGIS diagram so there's some different ways that you can you can do this we oftentimes just use the art catalogue Wizards of right-clicking new feature class and defining the attribute fields and the types as you go this is kind of the manual way here importing data builds schema as it comes in case tools or copying schema you you

Channel: Pete Kennedy

Views: 10,328

Rating: 4.8588233 out of 5

Keywords: Geodatabase, Design, A-B Tech, GIS, Asheville

Id: _gF__T9g_9w

Length: 23min 21sec (1401 seconds)

Published: Mon Mar 06 2017