|
UIAS Union Catalog Options One Database - Single record representing the titles held in the entire CSU. (Similar to SILO - State Library of Iowa) This first option is to collect all of the information in one database and let the system software ( Horizon) control how to manage each of the different locations ( libraries). Holdings level information would be a single item for each campus who owns at least one copy of the title. Status and availability would be available from the local system. This option allows the software ( Sybase) to build a unique set of indexes that all sites share. This allows for quicker access to the total collection of the information because it is in one database/index. For any given title, there would be one master bib record with items attached indicating that at least one copy of the title is held by a campus. The day to day operations are smaller with this option. The System administratorís job would be to make sure that one database is both backed up and a consistency checker is run on that database. With this option there would be a space savings as well. Because you are only loading one database and all of its tables, stored procedures, and triggers it would not have to be duplicated in the other databases. There would be no duplication of bibliographic data as well. Ideally, this option will require that the data sets be collected and de-duplicated prior to loading. If loading and De-duplication were to be done one data set at a time, the length of time to load would be much greater. This will also assume that an acceptable match point and "Master Record Selection" strategy will be defined and decided upon by the UIAS. From an implementation point of view this would be the easiest and cleanest option. This method is already proven with our customer in Iowa and the programs for maintaining the database are already in place. A down side is the need to have decide on match points and whoís is the ëfinalí record for each bib. Another possible negative is the need to have all 22 campusí records combined prior to the original load. An additional potential challenge is that CSU would have to agree on who does updates to the catalog other than adding deleting, and updating items. There is also the need to come up with a way of supplying records to the union database on an ongoing basis. Iowa ëfiltersí all of their bibliographic changes through a data vendor. As Horizon moves forward and the union cataloging functionality of the software increases, this option will match more closely in some ways the designs that are being put into place. One area of future Union functionality will allow for the automatic updating of diverse database bases via Z39.50 to a central database Union Catalog.
This model is similar to the one mentioned above with the exception that all of the 22 campusí records will be loaded into the system. The disk space requirements would be much greater due to duplication of Bib records. The Master record would be the main entry point (indexed record) into the catalog. Linked Records would be accessible from the linked records. Administration tasks would be similar to the one database mode above, with the exception that the database will be much larger.. Implementation and Data loading would be more complex. An algorithm for matching and linking would have to be created. The link tags (needed to establish the master/child hierarchy) have to be in place prior to loading so in the process we would have to do all the work of over laying with out over laying. In the end you have 22 duplicate bibs linked to one record. Without extensive work to ëhideí the subordinate records, the indexes would still reflect the duplicate records. This option is by far the most complex, and for the time being would not be my recommendation. Multiple Databases This model, sometimes referred to as the "IU model" calls for each library having and maintaining their own separate database on the Union server and then the patrons who search the database would be given a ëunion viewí of the overall CSU system. The big advantage to having separate databases is the ability to restrict access and hence changes to any other site other that the owning site. It makes the issue of having security in place moot. Remembering that Horizon handles security and rights to what each person can see and do at the individual level this issue is not as important as it could be. However, the best method to secure a database from other is not to allow them to access it. The individual databases in this solution would be smaller in size. This would allow for System administrator to backup individual database in a much faster manner. The down side of this is that s/he would have to backup and maintain many more databases. At Software/Database upgrade time, this would also indicate needing to upgrade each individual database. Broadcast searching would have to be used to search all of the databases and de-duplicate the results onto one screen. This would not be the case in a single database. Each site would have their own location and the library/and the patron could select which sites were to be included in the search. At Indiana University, they are using this model, however there are some things to be aware of that make this option good for them. IU is providing a single data source (LMS) and are doing a large amount of work and customizations on the Pro-index side of the system. IU is making this work, and it is really in the "experimental phase." IU has a technical staff that works full time to make this a possible solution. This option may be more geared for a ìlive consortiumî that is using the system as the local integrated solution and not just as union catalog. At IU where it is their local system, every one is using their own databases in production mode and maintenance comes naturally.
-Steven |
|
|
|
