Archive for the ‘Data models’ Category

As you know mySQL is a RDBMS  (Relational Database Management System) database engine that most of PHP developers (a essential component of the widely used LAMP web application software stack) use it as data storage.

This popular database is used in  most web applications which using PHP or perl as server script.

Original development of MySQL by Michael Widenius and David Axmark (beginning in 1994).

Current version is 5.5.13 ] Click here to get last release

More info:

• MySQL at Wikipedia
• MySQL at Wikibooks

Official website: http://www.mysql.com/

Best DB interface tools:

Web based:

• PHPMyAdmin (I LOVE IT!)
• SQL Buddy

Windows Application:

• EMS SQL Manager for MySQL
• HeidiSQL
• Toad for MySQL
• MySQL Workbench
• SQLyog
• Navicat for MySQL

syslog mysql interface

http://www.freedownloadmanager.org/downloads/mysql_gui_software/

Object-Oriented DBMSs

Adaptive Object Storage v1.0
GemStone Object/Web Server
HyBase
IDB Object Database
Jasmine
JiOMA
NeoAccess
O2 ODMG Database System
Objectivity/DB 4.0
ObjectStore
ObjectStore PSE Pro
Persistence Object FrameWork
Phyla
POET 3.0
Poet Universal Object Server
Polyhedra
Raima Object Manager
Secant Persistent Object Manager
Versant ODBMS 5.0

Here is a list of some RDBMS`s engine:

• 4th Dimension
• Adabas D
• Alpha Five
• Apache Derby
• Aster Data
• Altibase
• BlackRay
• CA-Datacom
• Clarion
• CSQL
• CUBRID
• Daffodil database
• DataEase
• Data Management Center (DMC)
• Database Management Library
• Dataphor
• Derby aka Java DB
• ElevateDB
• Empress Embedded Database
• EnterpriseDB
• EffiProz
• FileMaker Pro
• Firebird
• FrontBase
• Greenplum
• GroveSite
• H2
• Helix database
• HSQLDB
• IBM DB2
• IBM Lotus Approach
• IBM DB2 Express-C
• Infobright
• Informix
• Ingres
• InterBase
• InterSystems Caché
• GT.M
• Kognitio
• Linter
• MariaDB
• MaxDB
• Mckoi SQL Database
• Microsoft Access
• Microsoft Jet Database Engine (part of Microsoft Access)
• Microsoft SQL Server
• Microsoft SQL Server Express
• Microsoft Visual FoxPro
• Mimer SQL
• MonetDB
• mSQL
• MySQL
• Netezza
• NonStop SQL
• Openbase
• OpenLink Virtuoso (Open Source Edition)
• OpenLink Virtuoso Universal Server
• Oracle
• Oracle Rdb for OpenVMS
• Panorama
• PostgreSQL
• Progress Software
• RDM Embedded
• RDM Server
• The SAS system
• SAND CDBMS
• Sav Zigzag
• ScimoreDB
• SmallSQL
• solidDB
• SQLBase
• SQLite
• Sybase Adaptive Server Enterprise
• Sybase Adaptive Server IQ
• Sybase SQL Anywhere (formerly known as Sybase Adaptive Server Anywhere and Watcom SQL)
• Sybase Advantage Database Server
• tdbengine
• Teradata
• TimesTen
• txtSQL
• UniData
• UniVerse
• Vertica
• VMDS

In 1975, the American National Standards Institute (ANSI) published its “3-schema approach” to viewing data.3 As they the Institute saw it, there were at least three different perspectives on data. (Actually, in various drafts, they saw many more perspectives than that, but these have survived.)

External

Everyone in an organization looks at its data slightly differently. Each person holds in mind a “schema” or structure that is the representation of his/her surroundings from a particular point of view. Each of these schemas describing the world as one person sees it is called by ANSI an external schema. While, ideally, these are similar for the many people working in a company, as often as not they are in fact very different. Misunderstandings about what something means are at the heart of many systems (and management) problems in companies today.

Because of their diversity, it is not practical to draw a picture of each person’s view of their data, but it is appropriate when surveying these points of view to assemble an ontology or glossary of the language used throughout the organization. Where terms have different meanings or there are different terms for the same thing, these differences should be made explicit.

Conceptual

All of these participants in an organization are, after all, fundamentally looking at the same business, even if their perspectives are different. The objective of a good systems analyst is to integrate the set of external schemas to produce a single conceptual schema which represents the fundamental structure of the organization’s data.

The data model that portrays a conceptual schema consists of boxes representing the things of significance to it, along with lines describing how they are related to each other. (This is often referred to as an “entity/relationship” or “E/R” model.)

These conceptual schemas can be rendered at various levels of abstraction.

• An enterprise abstract conceptual data model is in terms of things that apply to the organization as a whole. This presents a general structure for addressing people and organizations, geography, physical assets, activities, and corporate objectives.
• A purpose-oriented concrete conceptual data model is in terms of a language that is relatively close to a particular area or function of the organization, such as contracting, human relations, or manufacturing. It represents assertions that are true for anyone working in that area, given the policies and procedures of the overall organization, but these are usually about things that are specific to that part of it. The project concrete model is then made up of: 1) sub-types of the enterprise entity classes, 2) “views” (analogous to SQL views) of sets of entity classes and relationships, and 3) new entity classes.

Internal

ANSI originally described the internal schema as the way data are represented in a physical storage medium. This included the use of random-access storage, tracks and cylinders, and so forth. With the advent of database management systems, however, this was broken into two schemas:

• A logical schema described data in terms of a particular data management technology. In the early days, this might have been a hierarchical database management system (DBMS), or a networked one. In more recent times, this describes the tables and columns of a relational DBMS, the classes of an object-oriented program, or XML tags.
• Database technology has advanced to the point that a true physical schema describing the physical architecture of a database is more important than ever. A set of tables and columns in a logical database may be implemented in many pieces scattered all over the world.

Note that along with relational database design, XML is one of several options for implementing a conceptual data structure. XML scripts are examples of logical schemas. As with relational database designs and object-oriented UML diagrams, these should be derived from a conceptual data model – not a replacement for it.

Note that in each of these technologies, trade-offs must be made in translating from the conceptual model. Relational database design does not recognize super-/sub-type structures, so adjustments must be made. XML is fundamentally hierarchical, so the translation from a two-dimensional data model will involve de-normalization that will sacrifice some flexibility.