Scribd
Upload
4 views

Database

The document discusses database design and the activities involved in transforming requirements into specifications to guide implementation. It describes two forms of specifications - logical specifications that map the conceptual data model and physical specifications that define parameters for data storage. During this phase, the database is defined using a data definition language.

Uploaded by

Vince Jeus Galamiton
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
4 views

Database

The document discusses database design and the activities involved in transforming requirements into specifications to guide implementation. It describes two forms of specifications - logical specifications that map the conceptual data model and physical specifications that define parameters for data storage. During this phase, the database is defined using a data definition language.

Uploaded by

Vince Jeus Galamiton
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Database design

The activities of database design transform the requirements for data


storage developed during database analysis into specifications to guide database
implementation. There are two forms of specifications:
1. Logical specifications, which map the conceptual requirements into the
data model associated with a specific database management system.
2. Physical specifications, which indicate all the parameters for data storage that are then used as input
for database implementation. During this
phase, a database is actually defined using a data definition language.
unified modeling language
Unified Modeling Language (UML) is a set of graphical notations backed by a common metamodel that is
widely used both for business modeling and for specifying, designing, and implementing software
systems artifacts. It culminated from the efforts of three leading experts, Grady Booch, Ivar Jacobson,
and James Rumbaugh, who defined this object-oriented modeling language that has become an industry
standard. UML builds upon and unifies the semantics and notations of the Booch (Booch, 1994), OOSE
(Jacobson et al., 1992), and OMT (Rumbaugh et al., 1991) methods, as well as those of other leading
methods.
Understand use of supertype/subtype relationships
Subtype A subgrouping of the entities in an entity type that is meaningful to the organization and that
shares common attributes or relationships distinct from other subgroupings.
Supertype A generic entity type that has a relationship with one or more subtypes.

Basic Concepts and Notation


The notation that is used for supertype/subtype relationships in this text is shown in Figure 3-1a. The
supertype is connected with a line to a circle, which in turn is connected with a line to each subtype that
has been defined. The U-shaped symbol on each line connecting a subtype to the circle emphasizes that
the subtype is a subset of the supertype.

An Example of a Supertype/Subtype Relationship Let us illustrate supertype/ subtype relationships with


a simple yet common example. Suppose that an organization has three basic types of employees: hourly
employees, salaried employees, and contract consultants. The following are some of the important
attributes for each of these types of employees: • Hourly employees Employee Number, Employee
Name, Address, Date Hired, Hourly Rate • Salaried employees Employee Number, Employee Name,
Address, Date Hired, Annual Salary, Stock Option • Contract consultants Employee Number, Employee
Name, Address, Date Hired, Contract Number, Billing Rate
Notice that all of the employee types have several attributes in common: Employee Number, Employee
Name, Address, and Date Hired. In addition, each type has one or more attributes distinct from the
attributes of other types (e.g., Hourly Rate is unique to hourly employees). If you were developing a
conceptual data model in this situation, you might consider three choices: 1. Define a single entity type
called EMPLOYEE. Although conceptually simple, this approach has the disadvantage that EMPLOYEE
would have to contain all of the attributes for the three types of employees. For an instance of an hourly
employee (for example), attributes such as Annual Salary and Contract Number would not apply
(optional attributes) and would be null or not used. When taken to a development environment,
programs that use this entity type would necessarily need to be quite complex to deal with the many
variations. 2. Define a separate entity type for each of the three entities. This approach would fail to
exploit the common properties of employees, and users would have to be careful to select the correct
entity type when using the system. 3. Define a supertype called EMPLOYEE with subtypes HOURLY
EMPLOYEE, SALARIED EMPLOYEE, and CONSULTANT. This approach exploits the common properties of
all employees, yet it recognizes the distinct properties of each type

Attribute Inheritance A subtype is an entity type in its own right. An entity instance of a subtype
represents the same entity instance of the supertype. For example, if “Therese Jones” is an occurrence
of the CONSULTANT subtype, then this same person is necessarily an occurrence of the EMPLOYEE
supertype. As a consequence, an entity in a subtype must possess not only values for its own attributes,
but also values for its attributes as a member of the supertype, including the identifier. Attribute
inheritance is the property by which subtype entities inherit values of all attributes and instance of all
relationships of the supertype.

When to Use Supertype/Subtype Relationships So, how do you know when to use a supertype/subtype
relationship? You should consider using subtypes when either (or both) of the following conditions are
present: 1. There are attributes that apply to some (but not all) instances of an entity type. For example,
see the EMPLOYEE entity type in Figure 3-2. 2. The instances of a subtype participate in a relationship
unique to that subtype. Figure 3-3 is an example of the use of subtype relationships that illustrates both
of these situations. The hospital entity type PATIENT has two subtypes: OUTPATIENT and RESIDENT
PATIENT. (The identifier is Patient ID.) All patients have an Admit Date attribute, as well as a Patient
Name. Also, every patient is cared for by a RESPONSIBLE PHYSICIAN who develops a treatment plan for
the patient

You might also like