|
|
||
|
|
||
|
|
||
In this chapter, you learned some of the important
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
To |
Do This |
|---|---|
|
Find sponsors for your project |
Write a business case that identifies the addressed business problem. |
|
Simplify the gathering of
|
Use domain experts that have a clear understanding of business. |
|
Obtain a better perspective of users needs |
Employ user interviews. |
|
Communicate with users and stakeholders |
Use a formal document to capture user requirements. |
|
Guarantee the operational viability of the solution |
Verify that operational requirements are
|
|
Estimate the amount of work that software and hardware will handle |
Use transaction cost analysis. |
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
After completing this chapter, you will be able to:
Model business needs
Validate business requirements through entity-relationship models
Understand Microsoft SQL Server 2005 datatypes
Enforce data integrity through table constraints
In this chapter, you will learn how to design and create a database to support business and application requirements. You will learn modeling techniques and practices that will assist in the process of transforming a business requirement document into the Transact-SQL (T-SQL) code required to create the database.
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
Database design is a critical part of the software development process. To ensure that the design fulfills business and operational requirements, database designers typically create three different database models, as shown in Figure 5-1.
Conceptual model
A high-level representation of
Logical model
Detailed representation of the software model that will capture the structured data. It helps to eliminate or at least drastically reduce data redundancy and
Physical model
Detailed specification of all tables and
Figure 5-1:
Three-Step Database Model
| Note |
To the untrained eye, this three-step process may seem time consuming, but that is not the case. Modeling the database in three steps offers a better quality control process and is frequently faster than a single-step design process. |
{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}
To comprehend and validate the business problem, database designers create conceptual models that serve as the foundation of logical and physical models. Four modeling techniques can be used to create conceptual models.
Object-Role Modeling (ORM)
Unified Modeling Language (UML)
Object-Oriented Systems Model (OSM)
Entity-Relationship modeling (ER)
| Note |
Microsoft Office Visio for Enterprise Architects supports ORM, UML, and ER diagrams. |
ER conceptual modeling is used in this book, but you should examine other models to discover a system with which you are comfortable.
To create a conceptual model of your application, you will need to examine all of the captured requirements and identify the following
Entities People, places, items, or concepts
Attributes Properties of an entity
Relationships Connections between entities
The best way to understand these concepts is by example. As part of the requirement-gathering process, assume that you obtain the following copy of an Adventure Works invoice.
On this invoice, you identify the following entities: Invoice, Invoice Line (Invoice Item), Customer, Order, and Payment. You also identify the following attributes of the Customer entity:
Several tools allow you to create ER diagrams, and Microsoft Visio for Enterprise Architects will be used in this book. This version of Visio is included in Visual Studio 2005 Team System (Developer, Tester, Architect) or as part of Visual Studio Professional with MSDN Premium.
From the Start menu, select Programs Microsoft Office Microsoft Office Visio For Enterprise Architects.
In the Choose Drawing Type window, select the Database category.
In the Database category, choose the Database Model Diagram or ER Source Model.
To document an entity in an ER Visio diagram, complete the following steps.
Drag and drop an entity shape from the
Select the recently added entity.
In the Database Properties window, choose the Definition category.
Name the entity using the Conceptual Name field.
Try to maintain a simple naming standard when naming objects. The object
To include attributes in the appropriate entity, complete the following steps.
Choose the Columns option in the Categories listbox, which is located to the left of the Database Properties window.
Add the attribute name in the Physical Name column.
You may also choose the attribute datatype at this time, but datatypes will be discussed in greater detail in the sections dealing with logical modeling.
In an ER diagram, relationships are represented with arrows. The arrow representing a relationship always points to the referenced entity. This means that the model would verify that the referenced element exists, and the integrity of the data is preserved for every referencing element. For example, when creating a relationship between the Cities and States/Provinces entities, the model would not allow the inclusion of a city that references a State or Province that does not exist.
Many types of relationships can be modeled in ER diagrams. The most common and simple type of relationship is the parent-child relationship . In this relationship, for each entity A, there are many entities B. Entity A is called the parent entity, and Entity B is the child entity. Parent-child relationships are also referred to as one-to-many relationships because one entity in the parent entity may be referenced by many entities in the child entity.
Drag and drop a relationship shape from the Shapes toolbar to the diagram surface.
Select the head of the arrow, and drag and drop it over the parent entity.
In a relationship between entities, the parent entity is the one that is referenced. For example, in the Customer-Invoice relationship, Customer is the parent entity and Invoice is the child entity.
Select the bottom of the arrow, and drag and drop it over the child entity.
When creating a conceptual model, you may encounter some
Modeling intersection relationships
Intersection relationships
possess a many-to-many association between entities, such as students and courses. Students may register for many courses, and courses may have
Drag and drop three entity shapes from the Shapes toolbar to the diagram surface.
Name the entities Students, Courses, and EnrolledStudents.
Add the required attributes to the Students and Courses entities.
Add two relationship shapes to the diagram surface.
Drag and drop the heads of both arrows over the EnrolledStudents entity.
Drag and drop the bottom of one relationship arrow over the Students entity and the bottom of the other relationship arrow over the Courses entity.
Add attributes to the EnrolledStudents entity.
To model a many-to-many relationship, add an additional table and establish two one-to-many relationships between the intersection entity and the other entities.
Modeling multi-intersection relationships The multi-intersection relationship uses the same guidelines as the intersection relationship, with the difference being that more than two tables participate in the relation. For example, assume that you want to enhance the previous model and capture information about scheduled courses in a university. You want to capture the relationship between courses, classrooms, professors, and schedules. The relationship can be modeled as shown in Figure 5-2.
Figure 5-2:
Example of a Multi-Intersection Relationship
Modeling self-referencing relationships
Self-referencing relationships
involve entities that reference
Drag and drop one entity shape from the Shapes toolbar to the diagram surface.
Name the entity Employee.
Add the required attributes to the Employee entity.
Add one relationship shape to the diagram surface.
Drag and drop the head of the relationship arrow over the Employee entity.
Drag and drop the bottom of the relationship arrow over the Employee entity.
After you have modeled all of the requirements and are satisfied with the model, it should be
| Tip |
Validate the database model early in the development process, for this will prevent costly mistakes in the construction phase. |
|
|
||
|
|
||
|
|
||