Database of Scriptum

A naming standard is a collection of rules, which, when applied to data, results in a set of data objects named in a logical and standardized way. These names convey some information about the named objects; an element name, for example, indicates the set of possible valid values (its data domain), and its usage. Having naming standards helps to achieve efficient use and reuse of data through better understanding of what data is in the system. Standardized names enhance communications about data within the BI community, from source application developers to BI experts to end users.

These standards apply to database objects created explicitly for Business Intelligence. Use reasonably meaningful names for tables and fields. If they get too long then try to use fairly standard (but consistent) abbreviations. If in doubt, just remove the vowels (a, e, i, o, u).
For each table also have a three letter acronym. Then if you have an 'ID' field that is used in foreign key relationships, then put the three letter acronym before the '_ID' name in ALL the tables that use it including the owning table.

Develop a list of standard suffixes, for example:
_FL for flags (usually only Y and N)
_IND for indicators (typically single byte varchar2 fields)
_NO for numeric numbers
_NUM for character numbers
_DT for dates
_TS for date-time stamps
 

If you have a set of tables that are closely related then SERIOUSLY consider giving them the same prefix or name root.

As far as object naming standards go, the advice above is as good as any. Most important is to BE CONSISTENT. Google "Database Naming Standards" and look at some of the documents you find - especially those on domains with .edu. - universities are red-hot on this sort of thing.
Also search for Oracle Database Design Standards, or variants of that phrase. Someone has done this already and will have published them on the web. 

The E-R approach is not a relative, a derivative, or a generalization of the relational data model, it is not a data model at all but a design methodology, which can be applied (but is not limited) to the relational model.

Main components of the E-R approach are the concepts of entity and relationship. Entities model the objects that are involved in an enterprise—for example, the patients, physicians, and procedures in a hospital. Relationships model the connections among the entities—for example, professors teach courses. In addition,
integrity constraints on the entities and relationships form an important part of an E-R specification, much as they do in the relational model. For example, A physician/ a doctor can only perform a surgery at a given time on a given day.

An entity-relationship (E-R) diagram is a graphical representation of the entities, relationships, and constraints that make up a given design. It provides a graphical summary of the design that is extremely useful to the designer, not only in validating the correctness of the design but also in discussing it with colleagues and in explaining it to the programmers who will be using it. But unfortunately, there is no standard drawing convention for E-R diagrams, and hence there is a good deal of variation among database texts in many aspects of this approach.

After the enterprise has been modeled with E-R diagrams, there are ways of converting these diagrams into sets of CREATE TABLE statements. But unfortunately, this conversion process does not yield a unique schema, especially in the presence of constraints, because some constraints that can be indicated in the E-R diagrams have no direct counterparts in SQL.

An important advantage of this methodology is that the designer can focus on complete and accurate modeling of the enterprise, without worrying about efficiently executing the required queries and updates against the final database. Later, when the E-R diagrams are to be converted to CREATE TABLE statements, the designer can add efficiency considerations to the final table designs using normalization theory and other techniques.

MySQL Workbench provides a graphical tool for working with MySQL Servers and databases. It fully supports MySQL Server versions 5.1 and above. It is also compatible with MySQL Server 5.0, but not every feature of 5.0 may be supported. It does not support MySQL Server versions 4.x.

MySQL Workbench is available in two editions, the Community Edition and the Standard Edition. The Community Edition is available free of charge. The Standard Edition provides additional Enterprise features, such as database documentation generation, at low cost. 

The Community Edition (OSS)

The Community Edition is the foundation of all MySQL Workbench editions—versions that are currently available or those that will become available in the future. All editions of MySQL Workbench are based on the Community Edition and all future improvements to the base framework and feature set will be included in this version. The Community Edition is a full feature product that puts a powerful database management tool into the hands of the MySQL community.

The Standard Edition

The Standard Edition is a commercial extension that builds on top of the OSS Edition and adds modules and plugins, enabling an optimized work flow. The highlights of this edition are:

DBDoc provides the following features:

A comparison of edition features can be found at MySQL Workbench Developer Central. 

MySQL Workbench is available for the following platforms:

Binary distributions of MySQL Workbench are available for the preceding platforms. Source code distributions are also available as a tar.gz package or an RPM package.

The following sections explain the installation process for each of these platforms.