Logical Database Design

Description Defines how the persistence aspect of the solution will be designed. In the case of a relational database, this task would begin to define the entity-relationship model. In the case of an object database, this task would define how the database will be used to store the objects (e.g. containerization strategy for Objectivity).
Risk & Impact This task serves two purposes. It provides a starting point for persistent which can be evolved and proven throughout the Object Interaction Diagrams to meet the business and technical needs of the project. It also serves as a reference point to judge the solution object model against, since they both must reflect a consistent semantic model. In the case of a relational database, the schema needs to be defined. Inadequate effort in this task may lead to a substandard design, exhibiting poor performance and/or a persistence solution incapable of storing the applications objects.
Inputs: Domain Model Design
Upstream Tasks: Domain Model Design
Downstream Tasks: Event Diagramming
Questions Asked:
  1. What are the actors defined in the use cases?
  2. What are the properties of the actors in the use cases?
  3. What are entities are implied by the use cases?
  4. What entities does the application architecture and design imply?
  5. What entities does the reuse analysis imply?
Iterates with: Requirements Use Cases
Deliverables: Logical Database Model – In the case of a relational database, this document is an ERA diagram showing the entities, relationships and attributes in the database schema. In the case of an object database, the documents describes the organization strategy used in the database, including containerization, name roots, access strategies, etc.