NivaarExam PrepOfficial exam papers ↗

18-Geom-A7 Geospatial Information Systems · May 2017

Question 10 of 15: Conceptual, logical and physical models

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

National Exams — May 2017 — 04-Geom-A7 Geospatial Information Systems. Closed-book; any non-communicating calculator permitted. Format: fifteen questions of varied value totalling 100 marks; fifteen questions constitute a complete paper and all fifteen are solved in full below. Most answers are required in essay form. Datum and coordinate conventions follow the Canadian spatial reference framework — NAD83(CSRS) horizontally and CGVD2013 vertically.

Reference texts: P. A. Longley, M. F. Goodchild, D. J. Maguire & D. W. Rhind, Geographic Information Systems and Science (4th ed., Wiley, 2015); P. Bolstad, GIS Fundamentals: A First Text on Geographic Information Systems (6th ed., XanEdu, 2019); P. A. Burrough, R. A. McDonnell & C. D. Lloyd, Principles of Geographical Information Systems (3rd ed., Oxford, 2015); M. Worboys & M. Duckham, GIS: A Computing Perspective (2nd ed., CRC, 2004); H. Samet, The Design and Analysis of Spatial Data Structures (Addison-Wesley, 1990); ISO 19115 Geographic information — Metadata.

Question 10: Conceptual, logical and physical models (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Database and geospatial design proceeds through three levels of abstraction, moving from the real world down to its stored implementation. Each is more concrete and more software-specific than the one above.

(1) Conceptual model. Defined as a high-level, software-independent abstraction of the real-world entities of interest, their attributes and the relationships among them — a statement of what is to be represented, not how. Produced by requirements analysis and abstraction with users and domain experts, deciding which real-world phenomena become feature types (e.g., parcels, roads, streams) and whether each is best seen as a discrete object or a continuous field. Represented by entity–relationship (E-R) diagrams, UML class diagrams or a feature catalogue — boxes for entities, lines for relationships, no reference to any particular GIS or DBMS.

(2) Logical model. Defined as the translation of the conceptual model into a specific data model (relational, object, vector or raster / geodatabase) while remaining independent of any particular product. Produced by mapping entities and relationships onto the chosen structure: tables with primary/foreign keys and normalization for the relational model, or feature classes, geometry types, topology rules and domains for a vector geodatabase; continuous fields become raster grids. Represented by a database schema — table/relationship diagrams, field lists with data types, and the geometry/topology definitions — still without physical storage detail.

(3) Physical model. Defined as the actual implementation of the logical schema in a specific DBMS or file format on real hardware — the level of how the data are stored. Produced by choosing the software (e.g., PostgreSQL/PostGIS, a file/enterprise geodatabase), creating the tables, geometry columns, spatial indexes (R-tree/quad-tree), tiling, storage parameters and access controls. Represented by the physical schema / data-definition language (DDL), index and storage specifications, and the files or tablespaces that hold the geometry and attributes. In short: the conceptual model says what, the logical model says in what structure, and the physical model says how it is actually stored.