Database Reference
In-Depth Information
you determine which entities your model will need and how these entities
are related. In addition we look at the attributes you need and explain how
to determine which type of data the attributes will store. We also go over
the diagramming method used in building the model. There are many
techniques for creating the data diagram, but we stick to one method
throughout this project.
Common Modeling Problems
In Chapter 8, Common Data Modeling Problems, we look at several com-
mon traps that are easy to fall into when you build your model. There are
many ways to build a logical model, and no single method is always the cor-
rect one. However, there are many practices that are always wrong, and
you can avoid them. Many aspects of data modeling are counterintuitive,
and following your intuition can lead to some of these problems. We go
through these problems and talk about why people fall into these traps,
how you can avoid them, and the appropriate ways to work around them.
Additionally, we look at a few things, such as subtype and supertype mod-
eling, that aren't necessarily problems but can be tricky.
Building the Physical Model
Once you have the logical model hammered out, you translate it into a
physical model, and we turn to that topic in Part IV. A physical model is
made up of the tables and other physical objects of your RDBMS. Much
of the work of creating your database has been completed during the log-
ical modeling, but that doesn't mean you should take the physical model
lightly. Logical models are meant to map to logical, real-world entities,
whereas the physical model defines how the data will be stored in the data-
base. At this point the focus is on ways to store data in the database to meet
the business requirements for data retrieval. This is where an intimate
knowledge of the specific RDBMS system is invaluable.
Creating the Physical Model
The first step is to create the model. In Chapter 9 we look at how you de-
termine which tables and keys you need based on your logical model. In
some cases you will end up with more than one table to represent a single
logical entity, whereas in other cases you will roll up multiple entities onto
a single table.
Search WWH ::
Custom Search