Entity relationship diagram as relational notation.
Representing Entities using Relational Notation
Question: Is representing entities with relational notation easier to understand than representing the same entities graphically?
The answer is that for some students relational notation will seem quite natural and for others it will take some getting used to. I will continue to represent entities using both styles, so if you prefer graphics to relational notation you will have a visual reference to make the explanations more understandable. All I ask is that you learn how to read relational notation. Doing so will allow you to study beyond this course and take advantage of resources that use relational notation to present their material.
Relational databases play a critical role in many important computer applications.
As is the case whenever enormous amounts of money are at stake, people have spent a huge amount of time and effort building, studying, and refining relational databases. Database researchers usually approach relational databases from one of three points of view.
First Group
The first group approaches the problem from a database-theoretical point of view. These people tend to think in terms of provability, mathematical set theory, and propositional logic. Theorists use phrases such as
relational algebra,
Cartesian product, and
tuple relational calculus.
This approach is intellectually stimulating and can be a bit intimidating. These researchers focus on logical design and idealized database principles.
Second Group
The second group approaches the topic from a less formal and practical point of view. Their terminology tends to be less precise and rigorous but more intuitive. They tend to use terms that you may have heard before such as table, row, and column. These people focus
on physical database design and pay more attention to concrete bits-and-bytes issues dealing with actually building a database and getting the most out of it.
Third Group
The third group tends to think in terms of flat files and the underlying disk structure used to hold data.
Though these people are probably in the minority these days, their terms file, record, and field made their way into database nomenclature and have remained. Many of those who still use these terms are programmers and other developers who look at the database from a consumer's " How do I get my data point of view". These differing points of view have led to several different and potentially confusing ways to view relational databases. This can cause some serious confusion, particularly because the different groups have latched on to some of the same terms but used for different meanings. In fact, they sometimes use the term relation in very different ways .
Constraints and Analysis
In the preceding course Relational Database Design, you created a Entity Relationship diagram to track
the products offered by and
orders placed with Stories on CD, Inc.,
a fictional company that sells books on CD principally by mail order.
In this module you will use a modified version of that ER diagram[1] to derive the database objects used to represent CDs, distributors, and orders in the database. When you begin to design the structure of your database, you will represent entities in the database as relations.
Other elements of relational constructs include the data domain of each field, the primary key of each relation, and any foreign keys. You will learn about each of those elements later in this module. Translating an ER diagram into relational notation[2] is a common step in the logical design stage of the database life cycle.
Once you have created relational notations based on the entities in your ER diagram, you can analyze them with an eye toward:
Ensuring that information is delivered in a consistent manner
Eliminating data redundancy
Preserving existing data when deleting unwanted data
It is possible to perform the analysis in this module and the next with the entities written as they are in the ER diagram, but
representing the entities in relational notation makes the task easier in three important ways:
Representing an entity in a text format is much more compact than representing the same entity graphically.
Some of the concepts in this course, such as functional dependencies and transitive dependencies, are customarily written (and are easier to explain) using relational notation.
Finally, if you choose to continue studying database design, you will almost certainly encounter relational notation in other courses or books.
Being able to read and write relational notation is a valuable skill.
The next lesson outlines the characteristics of tables, which are the objects that store database data.
Relations are expressed in a shorthand called relational notation, a textual interpretation of the ER diagram.
For example, a relation to store data about items stocked by Stories on CD, Inc. might be expressed this way in relational notation:
[1]ER diagram: (Entered in the glossary db under entity-relationship diagram.) A diagram used during the design phase of database development to illustrate the organization of and relationships between data during database design
[2]Relational notation: Relations are expressed in a shorthand called relational notation, a textual interpretation of the ER diagram.