Germany National Divisions — Versioned Administrative & Postal Data Platform

Data Engineering · Database Design · Administrative Geography · Postal Data · Versioning · Temporal Modeling · Open Data

A second-generation German administrative and postal data platform that evolves an earlier 2024 location/postcode dataset into a normalized, validated, versioned, portable, and historically aware data architecture. The V2 design follows the same preservation-first engineering principles used in the modernized Iran National Divisions project while adapting them to Germany’s own administrative and postal structure.

1. Project Overview

Germany National Divisions is a structured data-engineering project for representing German administrative locations and postal geography in a form that can be consumed reliably by software applications.

The first version was intentionally simple.

Its core purpose was to provide application-friendly access to:

German federal states,
places / localities,
postal codes,
and basic location relationships.

The original private SQL dataset stores records using fields such as:

id
postleitzahlen
bundesland
ort
created_at
updated_at

This was sufficient for practical address selection and postcode/location lookup.

The second generation changes the scope substantially.

The goal of V2 is not merely to add more rows.

It is to transform the project into a versioned administrative data platform.

2. Evolution

The project follows a clear two-generation path:

2024
Flat Location / Postal Dataset
        ↓
Real Application Use
        ↓
Identify Structural Limitations
        ↓
V2 Re-Engineering
        ↓
Raw + Canonical Architecture
        ↓
Normalized Administrative Hierarchy
        ↓
Postal Relationship Modeling
        ↓
Stable Official Identifiers
        ↓
Versioning + Temporal Changes
        ↓
Validation + Automated Testing
        ↓
Portable Database / Data Exports

3. Relationship to Iran National Divisions

Germany National Divisions V2 is conceptually the German counterpart to the modernized Iran National Divisions project.

The two projects share the same engineering philosophy:

Do not destroy the historical source in order to make the modern dataset cleaner.

Both projects separate:

Raw Source Data

from:

Canonical Application Data

and treat:

provenance,
normalization,
stable identity,
referential integrity,
versioning,
temporal change,
portability,
and automated validation

as first-class architectural concerns.

The German project does not copy Iran’s administrative hierarchy.

It applies the same architecture principles to Germany’s own structures.

4. Current Legacy Baseline

The original German dataset is a simple SQL representation centered around:

Postal Code
Federal State
Place

Conceptually:

PLZ → Bundesland + Ort

This works for many application dropdowns and address forms.

However, it does not sufficiently represent the complexity of real administrative and postal geography.

5. Why the Flat Model Is Insufficient

A flat table becomes problematic when software needs to answer questions such as:

Which municipality does this locality belong to?
Which district contains the municipality?
Which federal state contains the district?
What is the official administrative identifier?
Which postal codes belong to one municipality?
Which localities share one postal code?
How should repeated place names be disambiguated?
How should renamed or merged municipalities be represented?
How can historical address data remain valid after administrative changes?
Which snapshot of German administrative geography did an application use?

These requirements push the dataset beyond:

postcode + place name

into a real data-modeling problem.

6. Postal Geography Is Not a Simple Hierarchy

Postal geography and administrative geography are related but not identical.

A simplistic model such as:

One Postal Code → One City

is unsafe.

The original data already demonstrates cases where:

One city has multiple postal codes

and:

One postal code can occur with multiple place names

V2 therefore treats postal assignments as relationships rather than assuming a one-to-one mapping.

7. V2 Design Goal

The V2 objective is:

Preserve the original German location dataset while building a normalized, validated, versioned and historically aware administrative/postal data architecture around it.

The original source remains available.

The canonical representation can evolve independently.

8. Core Architecture

The planned V2 architecture separates the platform into several layers:

┌───────────────────────────────┐
│        Raw Source Layer       │
│ Historical imported datasets │
└──────────────┬────────────────┘
               ↓
┌───────────────────────────────┐
│ Normalization / Transformation│
│ Cleaning + Mapping + Identity │
└──────────────┬────────────────┘
               ↓
┌───────────────────────────────┐
│      Canonical Data Layer     │
│ Structured application model │
└──────────────┬────────────────┘
               ↓
┌───────────────────────────────┐
│ Validation / Integrity Layer  │
│ Tests + constraints + checks  │
└──────────────┬────────────────┘
               ↓
┌───────────────────────────────┐
│       Export / Delivery       │
│ CSV JSON SQLite SQL databases │
└───────────────────────────────┘

9. Preserve Source Truth

The first architectural rule is:

Raw imported data is evidence, not disposable staging data.

V2 should retain the original representation as faithfully as possible.

If a value appears suspicious, incomplete, duplicated, or outdated, the canonical layer may correct or reinterpret it.

The raw layer remains intact.

10. Raw vs Canonical

Raw Layer

Purpose:

provenance,
reproducibility,
source comparison,
migration verification,
historical auditability.

Canonical Layer

Purpose:

clean application consumption,
normalized names,
explicit relationships,
official identifiers,
constraints,
search,
exports.

This separation prevents normalization from silently rewriting history.

11. Canonical Administrative Model

The German canonical model should represent entities rather than duplicated location strings.

A high-level representation can include structures such as:

Germany
   ↓
Bundesland
   ↓
Administrative Regional Level
   ↓
Kreis / Kreisfreie Stadt
   ↓
Gemeinde / Stadt
   ↓
Ort / Ortsteil / Locality

Not every federal state uses every intermediate level.

Therefore V2 should not force one identical hierarchy onto all Länder.

12. State-Specific Administrative Structures

Germany contains administrative differences between federal states.

The architecture should therefore support optional intermediate levels.

Conceptually:

AdministrativeUnit
├── id
├── type
├── parent_id
├── official_code
├── name
└── validity

instead of hard-coding every possible level into one rigid path.

13. Generic Administrative Entity Model

A flexible canonical model could use:

AdministrativeUnit
├── internal_id
├── entity_type
├── parent_id
├── official_identifier
├── canonical_name
├── state
├── valid_from
├── valid_to
└── dataset_version

This makes hierarchy traversal possible while accommodating regional differences.

14. Entity Types

Possible administrative entity types may include:

country
bundesland
regierungsbezirk
kreis
kreisfreie_stadt
gemeinde
stadt
ort
ortsteil
other_local_unit

The exact final taxonomy should be derived from authoritative source data rather than assumptions.

15. Stable Identity

Names are not sufficient identifiers.

Different places can share the same name.

Names can also change.

V2 therefore separates:

Internal Database Identity

from:

Official Administrative Identity

and:

Display Name

16. Official Identifiers

Where available, V2 should preserve official German administrative identifiers such as:

municipal keys,
regional keys,
official statistical identifiers,
and other stable domain codes.

These values are domain data.

They should not be replaced by application-generated primary keys.

17. Internal ID vs Official Code

Conceptually:

id = 8472

may be an internal relational primary key.

An official administrative code is something different.

Both may coexist:

AdministrativeUnit
├── id
└── official_code

This separation gives the database flexibility without losing source semantics.

18. Postal Code Model

Postal codes should be represented independently from administrative units.

Conceptually:

PostalCode
├── id
└── code

with mapping tables connecting postal codes to locations.

19. Postal Assignment Model

Instead of:

place.postcode

V2 can model:

PostalCode
      ↕
PostalAssignment
      ↕
Locality / Municipality

This supports:

multiple PLZ values for one municipality,
multiple localities under one PLZ,
historical reassignment,
and future metadata.

20. Many-to-Many Postal Relationships

The data architecture should permit:

Municipality A
├── PLZ 1
├── PLZ 2
└── PLZ 3

and:

PLZ X
├── Locality A
├── Locality B
└── Locality C

without duplicating administrative identity.

21. Postal Assignment Entity

A canonical relationship could contain:

PostalAssignment
├── postal_code_id
├── administrative_unit_id
├── locality_id
├── valid_from
├── valid_to
├── source_id
└── dataset_version_id

This gives postal mappings their own lifecycle.

22. Repeated Place Names

Germany contains many repeated place names.

A place should therefore never be identified only by:

name = "Neustadt"

Identity should be determined through:

official identifier,
parent hierarchy,
postal context,
and stable internal key.

23. Canonical Names

The canonical layer should normalize naming consistently while preserving raw names.

For example:

raw_name
canonical_name

This allows transformations without losing provenance.

24. Text Normalization

German place data can contain:

umlauts,
ß,
hyphens,
abbreviations,
slash notation,
historical naming forms,
alternative spellings.

Normalization rules should therefore be explicit and reproducible.

25. Search Normalization

Search-friendly representations can be added without modifying canonical display values.

Example:

display_name  = "Großenhain"
search_name   = normalized searchable form

The original name remains intact.

26. Dataset Versioning

Administrative data changes.

Therefore one database snapshot should not be treated as eternal truth.

V2 should publish explicit versions.

Conceptually:

Germany Dataset 2024
Germany Dataset 2026
Germany Dataset Future-N

Each application can then identify which snapshot it consumes.

27. Version Entity

A dataset-version model could contain:

DatasetVersion
├── id
├── version
├── effective_date
├── created_at
├── source_summary
└── checksum

This improves reproducibility.

28. Why Versioning Matters

Without versioning:

today's Germany

silently replaces:

yesterday's Germany

With versioning, both can remain queryable.

29. Temporal Administrative Model

Snapshots alone do not explain change.

V2 should also represent events.

Examples:

creation
rename
merge
split
transfer
dissolution
postal_reassignment

30. Administrative Events

A temporal event model can describe:

AdministrativeEvent
├── type
├── effective_date
├── source_entities
├── target_entities
├── metadata
└── source_reference

This preserves continuity.

31. Example — Rename

Bad model:

Old name overwritten

Better model:

Entity A
Old Name
    ↓ rename event
New Name

The identity remains stable.

32. Example — Municipal Merge

Bad model:

Delete municipalities A and B
Create municipality C

Historical references then lose meaning.

Better model:

A ─┐
   ├── merge event → C
B ─┘

Historical records can continue referencing A and B.

33. Example — Transfer

If a locality changes its administrative parent:

Old Parent
    ↓
Transfer Event
    ↓
New Parent

the system preserves both states rather than overwriting the relationship.

34. Postal History

Postal relationships may also change.

The temporal model should therefore distinguish:

Administrative Change

from:

Postal Assignment Change

They are related but not identical.

35. Provenance

Every canonical record should be traceable to source information.

Conceptually:

Canonical Record
       ↓
Transformation
       ↓
Raw Record
       ↓
Source Dataset

This makes the pipeline auditable.

36. Source Registry

A source table could contain:

Source
├── id
├── name
├── publisher
├── reference
├── retrieved_at
├── license
└── checksum

This allows several source datasets to coexist.

37. Reproducible Transformation

Canonical data should be generated through code or explicit transformation rules.

Avoid:

manual silent edits

Prefer:

Raw Data
   ↓
Transformation Script
   ↓
Canonical Dataset

This makes the result reproducible.

38. Validation

A cleaner schema does not automatically mean better data.

V2 therefore requires automated validation.

Possible invariants include:

no invalid parent references,
no malformed PLZ values,
all Bundesländer resolvable,
official identifiers conform to expected structure,
canonical mappings preserve source rows,
no accidental loss during transformation,
version exports remain internally consistent.

39. Automated Tests

The project should treat data tests like application tests.

Test categories can include:

Schema Tests
Hierarchy Tests
Postal Tests
Transformation Tests
Preservation Tests
Export Tests
Regression Tests

40. Preservation Tests

A critical rule:

Modernization must not silently delete legacy source information.

Tests should compare:

Raw Input
vs.
Transformation Output

and flag unexpected loss.

41. Hierarchy Tests

Examples:

Municipality → valid district
District → valid state
Locality → valid parent

where the relevant hierarchy applies.

42. Postal Tests

Examples:

PLZ must preserve leading zeroes,
postal codes must be represented as strings,
assignment references must resolve,
duplicates must be intentional relationships rather than accidental row duplication.

43. Why PLZ Must Be Text

Postal codes such as:

must not be stored as integers.

Otherwise:

01067 → 1067

and the postal identifier is damaged.

V2 should preserve postal codes as fixed-format textual domain values.

44. Referential Integrity

Important relationships should be enforced where possible by database constraints.

The database should not rely solely on application code to remember that:

child.parent_id

must reference an existing entity.

45. Unique Constraints

Uniqueness should be based on domain semantics.

Examples may include combinations such as:

official_identifier + dataset_version

rather than simply:

name

because location names are not globally unique.

46. Canonical vs Display Data

The system can preserve several representations:

raw_name
canonical_name
display_name
search_name

when necessary.

This avoids making one string serve every purpose.

47. Multi-Database Support

Like the modern Iran dataset, V2 should not depend on one database ecosystem.

Target representations can include:

CSV
JSON
SQLite
MySQL / MariaDB
PostgreSQL

48. CSV Export

Useful for:

data analysis,
spreadsheet tools,
ETL,
interoperability.

49. JSON Export

Useful for:

APIs,
frontend applications,
hierarchical representations,
JavaScript ecosystems.

50. SQLite Export

Useful for:

desktop applications,
embedded tools,
mobile/offline use,
testing,
single-file distribution.

51. MySQL / MariaDB Export

Useful for:

conventional web applications,
Laravel applications,
existing hosting environments.

52. PostgreSQL Export

Useful for:

robust relational applications,
advanced data workflows,
analytical integration,
future spatial extensions.

53. Data Delivery Principle

Applications should consume the dataset without needing to understand the original ingestion process.

The project therefore separates:

Data Engineering

from:

Application Consumption

54. Application Use Cases

The resulting dataset can support:

address forms,
customer databases,
CRM systems,
logistics,
shipping,
administrative research,
geographic filters,
reporting,
demographic/statistical systems,
validation services,
location APIs.

55. Address Selection

Instead of hard-coded dropdowns:

Bundesland
   ↓
Municipality
   ↓
Locality
   ↓
Postal Code

can be generated from structured data.

56. Postal Lookup

Applications can support:

PLZ → matching places

without assuming only one result.

Likewise:

Place → all relevant postal codes

can be supported.

57. Administrative Traversal

A structured model enables queries such as:

Locality
  ↑
Municipality
  ↑
District
  ↑
Federal State

without parsing strings.

58. Historical Querying

A future application could ask:

What administrative structure was valid on a specific date?

The temporal model creates a foundation for that.

59. Current Repository Strategy

The German repository remains private while the V2 architecture is being strengthened.

This is intentional.

The goal is to publish the project when its structure and validation quality reach the desired standard rather than publishing the older flat dataset as the definitive version.

60. Why the Repository Is Private

Private status does not mean the project is conceptual.

The original SQL dataset already exists and is usable.

The repository remains private because:

the public release should represent the stronger V2 architecture rather than the early baseline.

61. Current Legacy Evidence

The existing SQL dump demonstrates the original model:

alle_orts
├── id
├── postleitzahlen
├── bundesland
├── ort
├── created_at
└── updated_at

This is the source layer that V2 can preserve and transform.

62. Legacy Dataset Strength

The original version successfully solved its initial problem:

provide a practical German place/postcode dataset for application use.

That work is not discarded.

It becomes historical source material.

63. Legacy Dataset Limitation

The weakness is architectural, not conceptual.

A flat location table cannot reliably represent:

official identity,
administrative hierarchy,
temporal change,
postal many-to-many relationships,
provenance,
versioning,
data validation.

V2 adds those missing layers.

64. Modernization Principle

The modernization follows:

Normalize by addition, not destruction.

This is the same preservation-first philosophy used in the Iran National Divisions redesign.

65. Engineering Challenge

The difficult part is not importing German place names into SQL.

The harder questions are:

What defines identity?
Which hierarchy is valid in each state?
How are postal areas related to administrative areas?
How are duplicate names disambiguated?
How should changes be modeled over time?
How can raw evidence and canonical data coexist?
How can future updates avoid regressions?

These are data-architecture questions.

66. V1 vs V2

V1

Primary goal:

Create a practical German location and postcode database.

Core representation:

PLZ + Bundesland + Ort

V2

Primary goal:

Preserve the original data while building a normalized, versioned, validated, portable and historically aware administrative/postal data platform.

67. Architectural Difference

The V2 difference is not:

more rows

or:

more SQL files

It is:

different data lifecycle architecture

68. Project Positioning

Recommended public title:

Germany National Divisions

Subtitle:

A versioned, relational and temporal dataset for Germany’s administrative and postal geography

69. Alternative Title

Germany Administrative & Postal Data Platform

This is slightly more explicit about the combination of:

Administrative Geography
+
Postal Geography

70. Website Hero

Germany National Divisions

Data Engineering · Administrative Geography · Postal Data · Versioning

A second-generation German administrative and postal data platform that preserves an earlier postcode/location dataset while introducing normalized hierarchical entities, explicit postal mappings, stable identifiers, versioning, temporal change modeling, validation, automated testing and portable exports.

71. Website Project Card

Germany National Divisions

Data Engineering · Database Design · Postal Geography

Re-engineering a German postcode/location database into a versioned and historically aware data platform with normalized administrative hierarchy, explicit postal relationships, validation, and multi-database exports.

72. Short Website Card

Germany National Divisions

A normalized, versioned and testable German administrative/postal dataset designed for reliable application integration.

73. One-Line Description

Re-engineered a German location/postcode dataset into a normalized, versioned and historically aware administrative data architecture.

74. CV Entry

Germany National Divisions — Data Engineering / Database Architecture

Re-engineering an existing German postcode and location dataset into a preservation-first administrative data platform. V2 separates immutable raw source data from a normalized canonical model, introduces explicit hierarchical entities and postal relationships, preserves official identifiers, models administrative changes over time, adds automated integrity/regression testing, and targets portable CSV, JSON, SQLite, MySQL/MariaDB and PostgreSQL representations.

75. Short CV Entry

Re-engineered a German postcode/location dataset into a normalized, versioned administrative/postal data platform with temporal modeling, validation and portable exports.

76. Architecture-Focused CV Entry

Applied preservation-first data architecture to German administrative geography, separating raw and canonical datasets while modeling hierarchy, postal many-to-many relationships, stable identity, temporal changes and cross-database portability.

77. Interview Story — Situation

I originally had a practical German dataset containing:

postal code,
federal state,
place.

It worked for simple application use.

But after rebuilding my much larger Iran National Divisions dataset, it became clear that the German project could benefit from the same architectural maturity.

78. Interview Story — Task

Transform the flat German dataset into a platform that can remain reliable as:

administrative structures change,
postal mappings evolve,
new data sources are added,
and multiple applications consume the data.

79. Interview Story — Action

I preserved the original dataset as immutable source material and designed a canonical model around it.

The V2 architecture separates administrative entities from postal assignments, uses stable identifiers rather than names as identity, supports versioned snapshots and temporal change events, validates hierarchy and mappings, and produces portable representations for different application stacks.

80. Interview Story — Result

The project evolves from:

a useful SQL location table

into:

a reusable administrative/postal data architecture

while preserving the original dataset.

81. Technical Interview Version

“The first German version was simple: postcode, Bundesland and Ort. That is enough for many address forms, but it is not a durable geographic model. A city can have several postcodes, one postcode can map to several localities, names repeat, administrative structures vary between Länder, and structures change over time. For V2 I’m applying the same preservation-first architecture I used on my Iran National Divisions project: keep the original raw data immutable, generate a canonical relational layer, separate postal mappings from administrative identity, preserve official codes, version snapshots, model temporal events and protect transformations with automated tests.”

82. Data Engineering Lesson

The project demonstrates:

A location list and a geographic data platform are different things.

A list answers:

What strings exist?

A platform must answer:

What entity is this?
Where does it belong?
What identifies it?
When was this structure valid?
What changed?
Which source supports it?

83. Portability Lesson

Administrative data becomes much more useful when the consuming application does not need the original database engine.

Portable exports reduce coupling.

84. Historical Data Lesson

Overwriting administrative changes makes old data appear as if today’s boundaries always existed.

Temporal modeling avoids that distortion.

85. Postal Modeling Lesson

Postal codes are operational routing identifiers.

Administrative entities are governmental/statistical entities.

The two systems overlap but should not be collapsed into one identity model.

86. Planned Release Quality

The public V2 should ideally include:

documented schema,
source provenance,
raw dataset preservation,
transformation scripts,
normalized canonical dataset,
integrity constraints,
automated tests,
version metadata,
temporal events,
portable exports,
reproducible build instructions.

87. Suggested Repository Structure

germany-national-divisions/
├── README.md
├── LICENSE
├── data/
│   ├── raw/
│   ├── canonical/
│   └── versions/
├── schema/
│   ├── sqlite/
│   ├── mysql/
│   └── postgresql/
├── exports/
│   ├── csv/
│   └── json/
├── scripts/
│   ├── import/
│   ├── normalize/
│   ├── validate/
│   └── export/
├── tests/
└── docs/

88. Suggested Core Tables

A possible relational model:

dataset_versions
sources
administrative_units
administrative_names
administrative_relations
postal_codes
postal_assignments
administrative_events
raw_records

The final implementation should follow actual source semantics.

89. Suggested Administrative Unit Table

administrative_units
├── id
├── official_identifier
├── type
├── canonical_name
├── parent_id
├── valid_from
├── valid_to
└── dataset_version_id

90. Suggested Postal Tables

postal_codes
├── id
└── code

and:

postal_assignments
├── id
├── postal_code_id
├── administrative_unit_id
├── valid_from
├── valid_to
└── dataset_version_id

91. Suggested Event Table

administrative_events
├── id
├── event_type
├── effective_date
├── source_entity_id
├── target_entity_id
├── dataset_version_id
└── notes

More complex split/merge events can use junction tables rather than forcing one-to-one event relationships.

92. Suggested Validation Suite

Potential automated tests:

01_raw_rows_preserved
02_postal_codes_are_five_characters
03_no_invalid_parent_reference
04_all_state_entities_resolve
05_official_codes_unique_per_version
06_no_orphan_postal_assignment
07_raw_to_canonical_mapping_complete
08_export_row_consistency
09_sqlite_import_valid
10_mysql_import_valid
11_postgresql_import_valid
12_json_schema_valid
13_temporal_ranges_valid
14_event_references_valid
15_no_unexpected_regression

The final suite can grow as V2 matures.

93. Public Release Philosophy

Do not publish simply because the data exists.

Publish when:

Source
+
Schema
+
Validation
+
Documentation
+
Reproducibility

are strong enough that another developer can trust and reuse the dataset.

This is the reason the repository remains private during V2 development.

94. Portfolio Tier

Recommended after V2 completion:

Tier A — Featured Data Engineering Project

Together with Iran National Divisions, it creates a strong paired portfolio story:

Iran
+
Germany

showing that the architecture is not limited to one national administrative system.

95. Career Evidence

The V2 project demonstrates:

Data Engineering
Relational Database Design
Administrative Geography Modeling
Postal Data Modeling
Raw/Canonical Separation
Data Provenance
Stable Identifier Design
Referential Integrity
Temporal Modeling
Dataset Versioning
Automated Validation
Regression Testing
Multi-Database Portability
Legacy Modernization

96. Suggested Tags

Germany
Administrative Divisions
Postal Codes
Data Engineering
Database Design
Open Data
Relational Data
Temporal Data
Versioning
Data Validation
Data Migration
SQLite
MySQL
MariaDB
PostgreSQL
CSV
JSON
Administrative Geography
Postal Geography

97. Suggested Website Metadata

Page Title

Germany National Divisions — Versioned Administrative & Postal Data

Meta Description

A preservation-first German administrative and postal data platform with normalized hierarchy, explicit postcode relationships, official identifiers, dataset versioning, temporal change modeling, automated validation and portable database exports.

Suggested Slug

/germany-national-divisions

98. Evidence Boundary

Already supported by the legacy project:

German location dataset exists,
private repository exists,
SQL representation exists,
current baseline includes postal code,
Bundesland,
Ort,
timestamps,
original data dates from the 2024 generation of the project.

V2 target architecture:

raw/canonical separation,
stronger administrative hierarchy,
official identifiers,
explicit postal relationships,
versioning,
temporal event modeling,
automated validation/tests,
multi-format/multi-database exports.

Until the V2 implementation is complete, these should be described as the V2 redesign architecture, not as already published production features.

99. Final Portfolio Statement

Germany National Divisions is the German counterpart to my administrative-data engineering work on Iran National Divisions. The original 2024 version provided a practical SQL dataset centered on postal codes, federal states and places. V2 re-engineers that baseline into a preservation-first administrative and postal data platform: the original source remains intact while a canonical model introduces explicit hierarchy, stable identity, official identifiers, many-to-many postal relationships, dataset versioning, temporal administrative events, automated validation and portable exports for modern application stacks. The objective is not simply to maintain a list of German places, but to provide a reproducible data architecture capable of evolving as administrative and postal structures change over time.

100. One-Line Summary

A second-generation German administrative and postal data platform designed around raw-data preservation, normalized hierarchy, versioning, temporal change and portable exports.

101. Ultra-Short Portfolio Label

Germany National Divisions — Data Engineering · Administrative Geography · Postal Data

Tags: Data Engineering Database Design GIS