Thinking at the Conceptual Level

Category: General
Reviewed by: artificer   
Reviewed on: Jun 02 2007
» Discuss this topic ( Posts)

To understand the context in which base fact types, constraints, and derivation rules take place, consider the following examples of portions of business domains. (The real domains would be much larger.) For each business domain, we will attempt inserts and deletes into the conceptual database to test these constraints. Here is an example.

Sample Domain: Apartment Complex

Base Fact Types:

- Remember, these are templates in which you can plug information, as we will see when we populate them later on.
  1. F1: Person (ID) has FirstName().
  2. F2: Person (ID) has LastName().
  3. F3: Person (ID) lives in Apartment(Nr).
  4. F4: Apartment (Nr) is in ApartmentBuilding (Nr).

Constraints:

- These specify what information is allowed and not allowed in the fact type populations.
  1. C1: Each Person has exactly one FirstName.
  2. C2: Each Person has exactly one LastName.
  3. C3: Each Person lives in at most one Apartment.
  4. C4: Each Apartment is in exactly one ApartmentBuilding.

Population:

  • "add," as its name implies, means we are trying to add information. "del" means we are trying to delete information. "begin" and "end" are used to do multiple operations. Constraints are evaluated only after the entire transaction has finished.
  1. add: Person with ID '1' has FirstName 'George'.
    • This would not go in, because it violates constraint C2.
  2. begin:
    • add: Person with ID '1' has FirstName 'George'.
    • add: Person with ID '1' has LastName 'Smith'.
    end
  3. This is accepted. Because this is done in a transaction, we evaluate constraints after both inserts are made.
  4. add: Apartment with Nr 1044 is in ApartmentBuilding with Nr 5.
    • This is accepted. No constraints are violated.
  5. add: Person with ID '1' lives in Apartment with Nr 1044.
    • This is accepted. No constraints are violated.
  6. del: Apartment with Nr 1044 is in ApartmentBuilding with Nr 5.
    • This is denied. Because Apartment 1044 is still in the information system (Person with ID '1' lives in Apartment with Nr 1044.) and every Apartment must be in an ApartmentBuilding, this violates C4.

The rest of these execises are for you to gain some familiarity with thinking at the conceptual level. The answers are at the bottom of the page. I will leave it up to you to decide whether the addition or deletion is allowed; if it is not allowed, try to figure out why it is not allowed.

Domain 1: General Store

Base Fact Types:

  1. F1: Employee (ID) has Name().
  2. F2: Employee (ID) was hired on Date(MDY).
  3. F3: Employee (ID) had employment terminated on Date(MDY).

Constraints:

  1. C1: Each Employee has exactly one Name.
  2. C2: If some Employee had employment terminated on Date then that Employee was hired on some Date.

Population:

  1. add: Employee with ID '1' has Name 'Alex Trebek'.
  2. add: Employee with ID '1' was hired on Date with MDY-CE Value 12-21-2006.
  3. add: Employee with ID '2' was hired on Date with MDY-CE Value 12-22-2006.
  4. del: Employee with ID '1' has Name 'Alex Trebek'.
  5. add: Employee with ID '3' has Name 'Brian Stanley'.
  6. add: Employee with ID '3' had employment terminated on Date with MDY-CE Value 12-27-2006.

Domain 2: Relationships

Base Fact Types:

  1. F1: Person (ID) has Name().
  2. F2: Person is a friend of Person.

Constraints:

  1. C1: Each Person has exactly one Name.
  2. C2: No Person is a friend of himself.
  3. C3: If Person 1 is a friend of Person 2, then Person 2 must not be a friend of Person 1.

Population:

  1. add: Person with ID '1' has Name 'Martin Hartford'.
  2. add: Person with ID '1' is a friend of Person with ID '1'.
  3. add: Person with ID '2' has Name 'Rex Rogers'.
  4. add: Person with ID '1' is a friend of Person with ID '2'.
  5. add: Person with ID '3' is a friend of Person with ID '2'.
  6. add: Person with ID '2' is a friend of Person with ID '1'.
  7. begin:
    • del: Person '1' has Name 'Martin Hartford'.
    • del: Person '1' is a friend of Person '2'.
    end
  8. add: Person '1' is of Gender 'M'.

Domain 3

Base Fact Types:

  1. F1: User(ID) has UserName
  2. F2: User has Password.
  3. F3: User has EmailAddress.

Constraints:

  1. C1: Each User has exactly one UserName.
  2. C2: For each UserName, at most one User has that UserName.
  3. C3: Each User has exactly one Password.
  4. C4: For each EmailAddress, at most one User has that EmailAddress.
  5. C5: Each User must have at most two EmailAddresses.

Population:

  1. add: User with ID '1' has UserName 'Artificer'.
  2. add: User with ID '1' has Password 'phE7aJe5'.
  3. begin:
    • add: User with ID '1' has UserName 'Artificer'.
    • add: User with ID '1' has Password 'phE7aJe5'.
    end
  4. add: User with ID '1' has EmailAddress 'one@devpen.com'.
  5. add: User with ID '2' has UserName 'Artificer'.
  6. begin:
    • add: User with ID '2' has UserName 'Redemption'.
    • add: User with ID '2' has Password 'phE7aJe5'.
    end
  7. add: User with ID '2' has EmailAddress 'two@devpen.com'.
  8. add: User with ID '2' has EmailAddress 'one@devpen.com'.
  9. add: User with ID '2' has EmailAddress 'three@devpen.com'.
  10. add: User with ID '2' has EmailAddress 'four@devpen.com'.

Answers

  • Domain 1
    1. Accepted.
    2. Accepted.
    3. Rejected. Violates C1.
    4. Rejected. Violates C1. (Every employee must have a name if any other information of theirs exists in the system, like hire date.)
    5. Accepted.
    6. Rejected. Violates C2.

  • Domain 2
    1. Accepted.
    2. Rejected. Violates C2.
    3. Accepted.
    4. Accepted.
    5. Rejected. Violates C1.
    6. Rejected. Violates C3.
    7. Accepted.
    8. Rejected. Not a fact type of interest.

  • Domain 3
    1. Rejected. Violates C3.
    2. Rejected. Violates C1.
    3. Accepted.
    4. Accepted.
    5. Rejected. Violates C1 and C2.
    6. Accepted.
    7. Accepted.
    8. Rejected. Violates C4.
    9. Accepted.
    10. Rejected. Violates C5.