1 / 19

The Finnish National Gallery Database implementation

The Finnish National Gallery Database implementation. Juha Inkari Aimari Oy inkari@iki.fi. The Finnish National Gallery Database implementation. Old/current relational database New relational database designed for CRM compatibility in mind

akio
Download Presentation

The Finnish National Gallery Database implementation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Finnish National GalleryDatabase implementation Juha Inkari Aimari Oy inkari@iki.fi

  2. The Finnish National Gallery Database implementation • Old/current relational database • New relational database designed for CRM compatibility in mind • Conversion application to copy database contents from the old database to the new database • Task specific user-interface (10 modules)

  3. Starting point • ”Flat” schema • Missing data or data in wrong place • First correct and cleanup data in the current/old database • average 1 error correcting update per row

  4. New database • SqlServer 2000 RDMS • can be managed • Use CRM as a guideline • Compatibility • in the future possible to export database in a CRM compatible XML Document

  5. Support for CRM • Mapping from current data structures and data to relevant CRM structures was done • Based on needed CRM structures a relational database schema was designed

  6. ”Flat” schema • Source database

  7. Step 1 : Add Events

  8. Step 2 : Add Actor

  9. Step 3 : Add Place

  10. Step 4 : Add Time-Span

  11. Add Activity and properties to support documentation needs

  12. Normalised database The normalised database has tables for • objects • actors • events • places • time-spans Yet there has not been a need to denormalise for performance

  13. Order or precedence • Catalogers want to keep the order of precedence • classifications • work of art is classified to be as more of a type ”drawing” than of a type ”painting” • materials and techniques • broader term like ”metal” before specialized term like ”bronze”. Also main materials are listed before supplemental and not so important materials.

  14. Production carried out by extensions • Order of precedence to keep list of artists in the precise order requested by the artists themselves • Note used to document unknown artists School of work • Belief/certainty field • Belief/certainty classification • Mutually exclusive cases

  15. Original and reproduction

  16. Missing original • Shortcut to enable joining subject and time of production for example

  17. Making CRM ”user friendly” • Users do have some kind of mental model about the system • our userbase refers to object records as ”cards” • Focus attention to the work problems like classification • Users could apply their CRM knowledge (if there would be any) to work problems

  18. Goals • Revise the cataloging rules from 1998 • the new cataloging rules should somehow refer to CRM • In the future with successfull training curators developing cataloging rules could also map those documentation needs to CRM

  19. Thats all folks

More Related