Este documento describe los conceptos fundamentales de las bases de datos orientadas a objetos, incluyendo la encapsulación, herencia y polimorfismo. También explica cómo los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos a través de interfaces y métodos. Además, introduce los conceptos de entidades, relaciones, tuplas y normalización que son importantes para el diseño de bases de datos.

2. Este modelo, bastante reciente, y propio de
los modelos informáticos orientados a
objetos, trata de almacenar en la base de
datos los objetos completos (estado y
comportamiento).

3. Una base de datos orientada a objetos es
una base de datos que incorpora todos los
conceptos importantes del paradigma de
objetos:
 Encapsulación – Propiedad que permite ocultar la
información al resto de los objetos, impidiendo así
accesos incorrectos o conflictos.
 Herencia – Propiedad a través de la cual los
objetos heredan comportamiento dentro de una
jerarquía de clases.
 Polimorfismo – Propiedad de una operación
mediante la cual puede ser aplicada a
distintos tipos de objetos.

4. En bases de datos orientadas a objetos, los usuarios pueden
definir operaciones sobre los datos como parte de la
definición de la base de datos. Una operación (llamada
función) se especifica en dos partes. La interfaz (o
signatura) de una operación incluye el nombre de la
operación y los tipos de datos de sus argumentos (o
parámetros). La implementación (o método) de la
operación se especifica separadamente y puede
modificarse sin afectar la interfaz.
En bases de datos orientadas a objetos, los usuarios pueden
definir operaciones sobre los datos como parte de la
definición de la base de datos. Una operación (llamada
función) se especifica en dos partes. La interfaz (o
signatura) de una operación incluye el nombre de la
operación y los tipos de datos de sus argumentos (o
parámetros). La implementación (o método) de la
operación se especifica separadamente y puede
modificarse sin afectar la interfaz.

5.  Sistema Gestor de Base de Datos. Un
Sistema Gestor de Base de Datos (SGBD, en
inglés DBMS: DataBase Management
System) es un sistema de software que
permite la definición de bases de datos; así
como la elección de las estructuras de
datos necesarios para el almacenamiento
y búsqueda de los datos, ya sea de forma
interactiva o a través de un lenguaje de
programación.

6. Un SGBD relacional es un modelo de datos que
facilita a los usuarios describir los datos que serán
almacenados en la base de datos junto con un
grupo de operaciones para manejar los datos.
Los SGBD relacionales son una herramienta
efectiva que permite a varios usuarios acceder a
los datos al mismo tiempo. Brindan facilidades
eficientes y un grupo de funciones con el
objetivo de garantizar la confidencialidad, la
calidad, la seguridad y la integridad de los datos
que contienen, así como un acceso fácil y
eficiente a los mismos.

7. Las bases de datos son un gran pilar de la
programación actual, ya que nos permiten
almacenar y usar de forma rápida y eficiente
cantidades ingentes de datos con cierta facilidad. En
la actualidad se usa de forma mayoritaria las bases
de datos relacionales (dominadas por distintos
gestores a través del lenguaje SQL, en gran medida).

8. Las entidades
representan cosas u objetos (ya sean reales o
abstractos), que se diferencian claramente
entre sí.
Para poder seguir un ejemplo durante el
artículo añadiré ejemplos sobre un taller
mecánico, donde se podría crear las
siguientes entidades:
 Coches (objeto físico): contiene la
información de cada taller.
 Empleado (objeto físico): información de los
trabajadores.
 Cargo del empleado (cosa abstracta):
información de la función del empleado.

9.  Otra de las características importantes
que hay que tener en cuenta en este
modelo es la cardinalidad de cada
extremo en una relación. La
cardinalidad expresa cuántas del
conjunto de entidades de un extremo
de la relación están relacionadas con
cuántas entidades del conjunto del otro
extremo. Pueden ser ``uno a uno'', ``uno
a varios'' o ``varios a varios''.

10.  Por ejemplo, un artículo puede ser
escrito por un solo autor o por varios,
pero nunca por ninguno; un autor
puede pertenecer a exactamente una
institución (no para cero o varias); un
artículo puede tener cero, uno o varios
experimentos.

11.  Las tablas de una base de datos
conforman la estructura principal de la
misma, podríamos decir que se trata de
los cimientos de nuestra estructura. Cada
tabla contiene la información que utilizarán
el resto de objetos de la base de datos:
consultas, formularios, informes...El diseño
de las tablas debe ser un proceso
meditado donde debemos tener en
cuenta las necesidades y el fin al que
estará destinada nuestra base de datos

12.  En las ciencias de la computación
una tupla puede tener dos significados
distintos. Generalmente en los lenguajes de
programación funcional y en otros
lenguajes de programación, una tupla es
un objeto que bien puede tener datos o
diversos objetos, de forma similar a una
tupla definida matemáticamente. Un
objeto de este tipo es conocido también
como record.
 Una definición más formal del anterior
párrafo sería: Conjunto de elementos de
distinto tipo que se guardan de forma
consecutiva en memoria.

13.  En algunos lenguajes y especialmente
en la teoría de bases de datos, una
tupla se define como una función finita
que mapea (asocia unívocamente) los
nombres con algunos valores. Su
propósito es el mismo que se definió en
las matemáticas.

14.  Relaciones 1 a 1
Las relaciones uno a uno No deben existir en una base de
datos pues eso denota inmediatamente que se hizo un mal
trabajo de normalización. Ya que cada tabla representa una
entidad de la base de datos. Una relación uno a uno,
significaría que cada tabla es 'media' entidad o dos tablas
representan un asunto o entidad. Lo correcto seria fusionar
las columnas de las dos tablas en una sola.
Siendo poco estrictos es verdad que existen relaciones uno a
uno en situaciones especiales (desnormalización planeada)
por convenir así; por ejemplo: si un campo de una tabla se
actualiza constantemente y queremos disminuir el riesgo de
colisión en bloqueos, se puede aislar ese campo en una
tabla que lo contenga y esté relacionado con una llave
primaria idéntica a la llave primaria de la primera tabla.

15.  Las relaciones uno a muchos son las mas
comunes y en realidad es la 'única'
relación válida para una base de datos,
así; un Cliente puede tener muchas
Facturas, una Población tiene muchos
Clientes y una Venta puede incluir
muchos Productos.

16. Las relaciones muchos a muchos
definitivamente son un tipo de relación que
no existen en una base de datos por una
simple razón... son imposibles de implementar
a menos que se haga un terrible trabajo de
diseño y por supuesto de normalización, ya
que implicaría que un mismo registro se
repitiera para cada relación.
Por ejemplo, para un Producto hay muchos
Proveedores y para un Proveedor hay
muchos Productos.

17. A este tipo de Entidades se les conoce
como Entidades débiles, ya que no
representan un asunto u objeto de la
realidad que intentan resolver. Dicho sea
de paso, este tipo de Entidades son
las únicas que llegan a cuarta o quinta
forma normal.

18. Uno de los factores mas importantes en la creación de
páginas web dinámicas es el diseño de las Bases de
Datos (BD). Si tus tablas no están correctamente
diseñadas, te pueden causar un montón de dolores de
cabeza cuando tengas de realizar complicadísimas
llamadas SQL en el código PHP para extraer los datos
que necesitas. Si conoces como establecer las
relaciones entre los datos y la normalización de estos,
estarás preparado para comenzar a desarrollar tu
aplicación en PHP. Si trabajas con MySQL o con Oracle,
debes conocer los métodos de normalización del
diseño de las tablas en tu sistema de BD relacional.
Estos métodos pueden ayudarte a hacer tu código PHP
mas fácil de comprender, ampliar, y en determinados
casos, incluso hacer tu aplicación mas rápida.

19.  Básicamente, las reglas de Normalización
están encaminadas a eliminar
redundancias e inconsistencias de
dependencia en el diseño de las tablas.
Más tarde explicaré lo que esto significa
mientras vemos los cinco pasos progresivos
para normalizar, tienes que tener en
cuenta que debes crear una BD funcional y
eficiente. Tambien detallaré los tipos de
relaciones que tu estructura de datos
puede tener.