[MUSIC] Hello, everyone, and welcome back. In this lesson, I'm going to show you some features specific to file geodatabases that make a nice work space and a few things about limit and considerations that you should be aware of when using them. We'll go over some things you need to know when sending file to databases to other people and also different data types and benefits of using them. So to start with I want to point out the importance of viewing your due databases in Arcmap rather than in Windows. Because when you view your folders that have the .gdb extension the true file due databases that I've created through the new menu here. In Arcmap or our catalog, it can understand this data, it interprets it correctly and we can use the data. It does the same for personal geo databases, so if I expand them, it understands them as a geo database but Windows does not. So if I try to navigate to the same location as this geo database in Windows I’ll show you what I get. So here’s the folder that contains it and what I see is, I see demos.gdb folder. Windows sees it as a file folder over here. It doesn’t see as a geo-database, it doesn’t know what a geo-database is. And if I click inside of it, I just see a bunch of random files. Its proprietary format that windows that not understand and I should not add files in Windows. I shouldn't remove files in Windows, those will both corrupt the Gio database. Instead I should understand that, I don't really want to mess with any Windows unless, the only action you can do in Windows is you could delete the whole thing. You could click on hit and hit the Delete key on your keyboard and remove the whole thing. I still say do that in ArcMap, just keep everything clean. But everything else, removing files once you're in the folder, don't do that. But, all you need to know is that if you want to send this hold you data base to somebody. You need send them this entire folder so, if you want to send it over the internet or something as a single file. You need to right click on a folder and if you have zip compression software install flix 7zip which is free. You can use that. Or, if you don't have it installed, you can use the Send To menu in Windows. And if you go to Send To, you can select compressed zip folder, and it will start compressing it and creating a single zip file for you to send your data. And here it is. So, it has the compression dialogue but it's also creating a folder for me here. That way, I will have one file to send the geo database to people with. Once that's complete though, in Windows, I can right click on it or double click it to open it up and extract that information out to a new folder again. Okay, let's also take a lot of some of these data again. And let's bring in our California counties layer. And if I go to the attribute table, I want to point out a couple things. First, these two fields get automatically added in file and personal geodatabases. So that's really nice. These get automatically calculated if I update the actual feature information in the layer and save it. So we automatically get these two fields with up to date shape information. Let's also take a quick look at the add field box because when we start using shape files we'll see it's a little different. If I could have double up I don't have to derive anymore information for a field of the double data type except if it's a double, where is on the shape file I'm going to have to provide some information about how long the field can be and how precise it should be. So it's kind of nice it just manages this data for us, it makes it a lot less complicated for you to get started with. You know everything already from our data types lecture that you need to know in order to use data types in this geodatabase. The other thing that's not totally clear, because this data originally came from a shapefile since so many people use shapefiles for data interchange, is that the database supports very long field names. So we could have used a field name of almost as long we wanted where shapefiles cap the field length at 13 characters. We can only use 13 letters and numbers to describe the, Shapefiles field name. So geodatabases, we can have very descriptive field names. Instead of name_cap we could have had name_capitalized, or something like that. Not a huge deal in this case, but there are plenty of cases where people start abbreviating their field names. Don't do that with file geodatabases. You don't even have to be descriptive and have people know intuitively what your fields mean without having to dig through your metadata. Similar to the limits on the names, file geodatabases also don't have really any practical limit on the size of the geodatabase or of any individual item in the geodatabase. They do have limits but I'd be surprised if any of you managed to hit them. You would need probably a cluster of computers to hit them on a, to fill up a full due database because you just don't have enough base on your hard drive. So they are really nice because they're not imposing any artificial limits on us. Whereas the mdb format that the access database format, the old access database format that personal geodatabases use is limited to two gigabytes. It makes it impractical to store any large rasters in there because rasters are usually pretty big. I have plenty of rasters on my computer that are larger themselves than two gigabytes. So, not only will it not fit in a geodatabase, but if they did in a personal geodatabase, they would make it like it can store anything else. In a file of geodatabase, I can store all this things in harmony and it will compress the data much better so that it's smaller in my hard drive and then even faster to access in most cases. That's why file geodatabases are great. They can be a little bit of a pain from viewing them in Windows standpoint, and they're proprietary so open source software has to take some extra steps to use it, but you can use them in QGIS and other open source GIS packages as well. The last thing is that file geodatabases are theoretically good for multi-user environments. So if I had them stored on a network drive or something and I was using this data someone else can use them at the same time. Now what happens is that, if when a user starts editing this layer, so if I start editing the California Counties layer and somebody else tries to open it at the same time, they can view it, but they can't edit it the same time. That makes some sense. Most people don't want to have two people editing the data at the same time because they could introduce conflicting at it so Arc JS prevents that. The big exception to that is our featured data sets where if we have multiple items in our feature dataset and we edit any feature class in our feature dataset, the whole feature dataset is locked. Which means that nobody can edit any of the other feature classes at the same time. But again they can view them, they can open them in ArcMap and take a look at them and add them to maps and stuff like that. One more thing, is that, two databases handle indexing for us. We haven't talked about indexing yet. Indexing is a great way to speed up access for large data sets. We can do it for attributes, and we can do it for spatial location. So we can go to Indexes here and we could see Spatial Index which is where ArcGIS figures out which items are in which area so that can very quickly draw our layers for us and geodatabases automatically create these, where for shapefiles we would have to create them ourselves. We can also add attribute indices, or attribute indexes, and I can create one right now and say, well I want to be able to search through the name field much more quickly. So I'm going to create an index on the name field and I'll add it over to the field selected and I'll click OK. And when I click apply, it runs through the names field and starts creating an index of values in that names field and this is going to make searches on that field, or even joins on that field much faster. In particular you do want your joined fields to be indexed. So we'd want to make that com ID field that we have used in the past to create that relate index. So let's make a com ID index 2. Note that these are two separate indexes though. They have to be separate. If they are the same it wouldn't make it so that it would index them together so that searches for the two of them together, we're faster but making separate indexes makes them each faster alone. Then, I'll click okay to close up. Okay. That's it for this lecture on file geodatabases. I showed you how they appear in our catalog, how they appear in Windows and how to send them. I also showed you that it automatically adds area fields and we talked about limits in file in geo databases. Namely that they don't have very many so we can store almost anything we want in them. And then also that we can edit one item at a time in file geodatabases but others can view them if this is stored on a shared location. And also we finally talked about indexing and how that speeds up our searching and our accessing of special locations and attributes. In the next lecture we'll going to take a look up a personal geodatabases, see you there.
