1 / 11

Ontologies and Databases: Use of ontology in database design

Ontologies and Databases: Use of ontology in database design. Matthew West Shell. Other Parts of. your Business. Government. Human. Resources. Your Business. Materials. Sales. Finance. Suppliers. Customers. Sharing Data. Management & Control. Life-Cycle. Supply Chain.

hesper
Télécharger la présentation

Ontologies and Databases: Use of ontology in database design

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. Ontologies and Databases: Use of ontology in database design Matthew West Shell

  2. Other Parts of your Business Government Human Resources Your Business Materials Sales Finance Suppliers Customers Sharing Data

  3. Management & Control Life-Cycle Supply Chain Different Dimensions to Integration

  4. How important is shared data? • Is the need to integrate the different parts of the business and their data vital to success? • Is it important that a consistent message is given to external organizations? • Are there problems reconciling data from different parts of the business? • Are you dissatisfied with the time scale and cost of enhancing existing systems? • Are you dissatisfied with the cost of obtaining data from existing systems for use elsewhere?

  5. Financial and time penalties • Translating data is expensive. • Interfaces can account for 25-70% of system costs. • The need to translate data means that users can only share data sequentially, not concurrently. • Impact on key business processes. • Slower response to the need for change in systems. • Interfaces cost time as well as money. • Quality suffers. • Interfacing may give rise to errors, and to inferior business decisions. • Time is wasted trying to locate and reconcile data.

  6. Operational & Transaction Data Summary Information • Reference Data • Products • Processes • Assets • Organisation • Location • Property Description Documents & Data Enterprise Information Architecture

  7. Reference Data & Description Documents Products Processes Assets Organisation Location Property Management Information Systems Operational Systems Information Systems Architecture Decision Support Systems

  8. Targets E n v i r o n m e n t KPI's measure and summarise compare Activities on observe The Enterprise The Ladder of Control

  9. Why do we need Data Models? A Data Model is a Language for Data You can only share information based on a common language. Each separate data model is it's own language (or rather a limited jargon). Creating a Standard Data Model gives the basis for sharing data within and between organizations and systems.

  10. High Cost of Systems Minor Changes System Repeated Component Major Rework Interfaces Development of Redevelopment same System "Same" Data Model Redeveloped Same thing Potential reuse Inflexible Data modelled differently not identified Models Insufficient Data Modelling Standards Issues for data modelling

  11. Data model wish list • Conceptual data models should: • meet the data requirement • be stable in the face of changing data requirements • be flexible in the face of changing business practices • be re-useable by others • be consistent with other models covering the same scope • be able to reconcile conflicting data models • be clear and unambiguous to all (not just the authors) • You should be able to develop data models that meet these requirements quickly, and at low cost

More Related