Definicin de Trminos Bsicos A continuacin se definen conceptos que fundamentan decisiones para en el diseo del guin.

Dado que estos trminos pueden tener acepciones ms complejas, de hecho, formar parte de teoras ms complejas, es importante sealar que las definiciones se limitan a lo que se puede aplicar en el proceso de escritura de un libro. El dato es una representacin simblica (numrica, alfabtica, algortmica, entre otros) de un atributo o caracterstica de una entidad. Los datos describen hechos empricos, sucesos y entidades. Los datos aisladamente pueden no contener informacin humanamente relevante. Slo cuando un conjunto de datos se examina conjuntamente a la luz de un enfoque, hiptesis o teora se puede apreciar la informacin contenida en dichos datos. Los datos pueden consistir en nmeros, estadsticas o proposiciones descriptivas. Los datos convenientemente agrupados, estructurados e interpretados se consideran que son la base de la informacin humanamente relevante que se pu eden utilizar en la toma decisiones, la reduccin de la incertidumbre o la realizacin de clculos. Es de empleo muy comn en el mbito informtico y, en general, prcticamente en cualquier investigacin cientfica. En programacin, un dato es la expresin general que describe las caractersticas de las entidades sobre las cuales opera un algoritmo. En Estructura de datos, es la parte mnima de la informacin.

La informacin est constituida por un grupo de datos ya supervisados y ordenados, que sirven para construir un mensaje basado en un cierto fenmeno o ente. La informacin permite resolver problemas y tomar decisiones, ya que su aprovechamiento racional es la base del conocimiento. Por lo tanto, otra perspectiva nos indica que la informacin es un recurso que otorga significado o sentido a la realidad, ya que mediante cdigos y conjuntos de datos, da origen a los modelos de pensamiento humano.

Una base de datos o banco de datos es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayora por documentos y textos impresos en papel e indexados para su consulta. Actualmente, y debido al desarrollo tecnolgico de campos como la informtica y laelectrnica, la mayora de las bases de datos estn en formato digital (electrnico), y por ende se ha desarrollado y se ofrece un amplio rango de soluciones al problema del almacenamiento de datos. Existen programas denominados sistemas gestores de bases de datos, abreviado SGBD, que permiten almacenar y posteriormente acceder a los datos de forma rpida y estructurada. Las propiedades de estos SGBD, as como su utilizacin y administracin, se estudian dentro del mbito de la informtica.

Las aplicaciones ms usuales son para la gestin de empresas e instituciones pblicas. Tambin son ampliamente utilizadas en entornos cientficos con el objeto de almacenar la informacin experimental. En computacin, un atributo es una especificacin que define una propiedad de un Objeto, elemento o archivo. Tambin puede referirse o establecer el valor especfico para una instancia determinada de los mismos. Sin embargo, actualmente, el trmino atributo puede y con frecuencia se considera como si fuera una propiedad dependiendo de la tecnologa que se use. Para mayor claridad, los atributos deben ser considerados ms correctamente como metadatos. Un atributo es con frecuencia y en general una caracterstica de una propiedad. Un buen ejemplo es el proceso de asignacin de valores XML a las propiedades (elementos). Tenga en cuenta que el valor del elemento se encuentra antes de la etiqueta de cierre (por separado), no en el propio elemento. El mismo elemento puede tener una serie de atributos establecidos (Nombre = "estoesunapropiedad"). Si el elemento en cuestin puede ser considerado una propiedad (Nombre_Cliente) de otra entidad (digamos "cliente"), el elemento puede tener cero o ms atributos (propiedades) de su propio (Nombre_Cliente es de Tipo = "tipotexto"). Un atributo de un objeto por lo general consiste de un nombre y un valor; de un elemento, un tipo o nombre de clase; de un archivo, un nombre y extensin. Cada atributo nombrado tiene asociado un conjunto de reglas denominadas operaciones: uno no agrega caracteres o manipula y procesa una matriz de enteros como una imagen ni procesa texto como tipo de coma flotante (nmeros decimales). Por tanto, una definicin de objeto se puede ampliar mediante la imposicin de tipos de datos: un formato de representacin, un valor por defecto, y las operacione s legales (normas) y restricciones ("Divisin por cero no esta permitida!") Son todos los que podran participar en la definicin un atributo, o por el contrario, se puede decir que son atributos de ese tipo de objeto. Un archivo JPEG no es decodificado por las mismas operaciones (por muy similares que sean, estos son todos formatos de datos de grficos) como un archivo BMP o PNG, ni es un nmero de coma flotante operado por las normas aplicadas al los enteros largos. Por ejemplo, en computacin grfica los objetos de planos pueden tener atributos tales como espesor (con valores reales), color (con valores descriptivos como el marrn o verde o los valores definidos en un cierto modelo de color, como RGB), etc Un objeto crculo se puede definir con atributos similares, como un origen y radio. Lenguajes de marca, como HTML y XML, utilizan los atributos para describir los datos y el formato de los datos. ENTIDADES, ATRIBUTOS Las entidades, atributos son conceptos importante de la base de datos. Una entidad es una clase generalizada de personas, lugares o cosas (objetos), para los cuales se recopilan, almacenan y mantienen datos. Un atributo es una caracterstica de una entidad. El valor especifico de un atributo, conocido como elemento de datos , se puede encontrar con los campos de registro que describe una entidad. Como ya se planteo, un conjunto de campos de una objeto especifico representa un registro. Cuna clave es un campo o grupo de campos en un registro que se utiliza para identificar a este.

Una base de datos relacional es una base de datos que cumple con el modelo relacional, el cual es el modelo ms utilizado en la actualidad para implementar bases de datos ya planificadas. Permiten establecer interconexiones (relaciones) entre los datos (que estn guardados en tablas), y a travs de dichas conexiones relacionar los datos de ambas tablas, de ah proviene su nombre: "Modelo Relacional". Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos. 1

Relaciones base y derivadas En una base de datos relacional, todos los datos se almacenan y se accede a ellos por medio de relaciones. Las relaciones que almacenan datos son llamadas "relaciones base" y su implementacin es llamada "tabla". Otras relaciones no almacenan datos, pero son calculadas al aplicar operaciones relacionales. Estas relaciones son llamadas "relaciones derivadas" y su implementacin es llamada "vista" o "consulta". Las relaciones derivadas son convenientes ya que expr esan informacin de varias relaciones actuando como si fuera una sola.

Principios de diseo de bases de datos 1 . Introduccin 2 . Almacenar slo la informacin necesaria 3 . Pedir slo lo necesario y ser explcito 4 . Normalizar las estructuras de tablas 5 . Seleccionar el tipo de dato apropiado 6 . Utilizar ndices apropiadamente 7 . Usar consultas REPLACE 8 . Usar tablas temporales 9 . Usar una versin reciente de MySQL 10 . Consideraciones finales Cedido por MySQL Hispano. Introduccin Uno de los pasos cruciales en la construccin de una aplicacin que maneje una base de datos, es sin duda, el diseo de la base de datos. Si las tablas no son definidas apropiadamente, podemos tener muchos dolores de cabeza al momento de ejecutar consultas a la base de datos para tratar de obtener algn tipo de informacin.

No importa si nuestra base de datos tiene slo 20 registros, o algunos cuantos miles, es importante asegurarnos que nuestra base de datos est correctamente diseada pa ra que tenga eficiencia y usabilidad a lo largo del tiempo. En este artculo, se mencionarn algunos principios bsicos del diseo de base de datos y se tratarn algunas reglas que se deben seguir cuando se crean bases de datos. Dependiendo de los requerimientos de la base de datos, el diseo puede ser algo complejo, pero con algunas reglas simples que tengamos en la cabeza ser mucho ms fcil crear una base de datos perfecta para nuestro siguiente proyecto. Construir grandes aplicaciones en MySQL resulta fcil con herramientas como Apache, Perl, PHP, y Python. Asegurarse de que son rpidas, sin embargo, requiere algo ms que perspicacia. MySQL tiene una bien merecida reputacin de ser un servidor de bases de datos muy rpido que tambin es muy fcil de configurar y usar, adems de que en los ltimos aos su popularidad ha crecido notablemente debido a que se utiliza en infinidad de sitios web que requieren hacer uso de una base de datos. Sin embargo, pocos usuarios sabemos algo ms que crear una base de datos y escribir algunas bsquedas contra ella. Despus de leer este artculo debemos ser capaces de entender algunas tcnicas que nos ayudarn a disear bases de datos MySQL para construir mejores aplicaciones. Vamos a suponer que se tiene un conocimiento bsico del lenguaje SQL, y de MySQL, pero no vamos a asumir que se tiene mucha experiencia en alguno de los dos. Almacenar slo la informacin necesaria Parece de sentido comn, pero muchas personas suelen tomar el enfoque de "sumidero de cocina" par a el diseo de bases de datos. A menudo pensamos en todo lo que quisiramos que estuviera almacenado en una base de datos y diseamos la base de datos para guardar dichos datos. Hemos de ser realistas acerca de nuestras necesidades y decidir qu informaci n es realmente necesaria. Frecuentemente podemos generar algunos datos sobre la marcha sin tener que almacenarlos en una tabla de una base de datos. En estos casos tambin tiene sentido hacer esto desde el punto de vista del desarrollo de la aplicacin. Por ejemplo, una tabla de productos para un catlogo en lnea puede contener nombres, descripciones, tamaos, pesos y precios de varios productos. Adems del precio, puede que se quieran guardar los impuestos y los gastos de envo asociados con cada producto . Pero realmente no hay ninguna necesidad de hacer esto. Primero, tanto los impuestos como los gastos de envo pueden ser calculados sobre la marcha (ya sea por nuestra aplicacin, o por MySQL). Segundo, si cambiamos los impuestos o los gastos de envo, tendramos que escribir las bsquedas necesarias para actualizar los impuestos y los gastos de envo en cada registro del producto. Algunas veces pensamos que agregar campos a las tablas de una base de datos una vez que han sido creadas es demasiado difcil, as que nos vemos impulsados a definir tantas columnas como se pueda. Bueno, esto simplemente es un concepto errneo, ya que en MySQL podemos usar el comando ALTER TABLE para modificar la definicin de una tabla en cualquier momento para que se adecue a n uestras necesidades cambiantes.

Por ejemplo, si en algn momento nos damos cuenta que necesitamos agregar una columna de popularidad a nuestra tabla productos (tal vez queramos que nuestros clientes califiquen los productos en nuestro catlogo), podramos hacer lo siguiente: ALTER TABLE productos ADD popularidad INTEGER; Pedir slo lo necesario y ser explcito Igual que decir "almacenar slo lo necesario", esto puede parecer un poco ms de sentido comn, sin embargo, esto no suele ser considerado muy a menudo. Por qu?. Porque cuando una aplicacin est en desarrollo los requerimientos suelen cambiar, de tal forma que muchas de las bsquedas terminan parecindose a esto: SELECT * FROM algunaTabla; Obtener todas las columnas de una tabla es simplemente lo m s conveniente que podemos hacer cuando no estamos seguros de qu campos necesitamos. Sin embargo, a medida que las tablas crecen y cambian, esto puede convertirse en un problema de rendimiento. A la larga es mucho mejor tardarnos un tiempo extra despus de nuestro desarrollo inicial y decidir exactamente qu es lo que necesitamos en nuestras bsquedas. En concreto, es mucho mejor especificar las columnas de forma explcita: SELECT nombre, precio, descripcion FROM productos; Esto se relaciona con un punto que tiene que ver ms con el mantenimiento del cdigo que con el rendimiento. La mayora de los lenguajes de programacin (Perl, Python, PHP, Java, etc) nos permiten acceder a los resultados de una consulta por los nombres de los campos y por su posicin numrica. Para el ejemplo anterior, podemos acceder al campo 0, o al campo nombre y obtener los mismos resultados. A la larga es mejor usar los nombres de columnas que sus posiciones numricas. Por qu? Porque las posiciones relativas de columnas en una tabla o en un resultado de una consulta pueden variar. Por ejemplo, pueden variar en una tabla como resultado de un ALTER TABLE, o bien, cambiarn en una consulta como resultado de que alguien rescriba la bsqueda y se olvide de actualizar la lgica de la aplicacin apropiadamente. Claro est, an debemos ser cuidadosos cuando cambiemos los nombres de las columnas! Pero si usamos nombres en vez de posiciones numricas, podemos usar la capacidad de bsqueda y reemplazo de nuestro editor para encontrar el cdigo que hemos de cambiar en caso de que cambie el nombre de una columna. Normalizar las estructuras de tablas Si nunca antes hemos odo hablar de la "normalizacin de datos", no debemos temer. Mientras que la normalizacin puede parecer un tema complejo, nos podemos beneficiar ampliamente al entender los conceptos ms elementales de la normalizacin. Una de las formas ms fciles de entender esto es pensar en nuestras tablas como hojas de clculo. Por ejemplo, si quisiramos seguir la pista de nuestra coleccin de CDs en una hoja de clculo, podramos disear algo parecido a lo que se muestra en la siguiente tabla. +------------+-------------+--------------+ .. +--------------+ | album | track1 | track2 | | track10 | +------------+-------------+--------------+ .. +--------------+ | Antrologia | Tarzan Boy | Life is life | .. | Square rooms |

| (Baltimora) | (Opus)

| .. | (Al Corley) |

+------------+-------------+--------------+ .. +--------------+ Esto parece razonable. Sin embargo el problema es que el nmero de pistas que tiene un CD es bastante variable. Esto significa que con este mtodo tendramos que tener una hoja de clculo realmente grande para albergar todos los datos, que en los peores casos podran ser de hasta 20 pistas. Esto en definitiva no es nada bueno. Uno de los objetivos de una estructura de tabla normalizada es minimizar el nmero de "celdas vacas". En el caso de la tabla de CDs que estamos tratando, tendramo s muchas de estas celdas si permitiramos CDs de 20 pistas o ms. En el caso de que las listas de campos pueden expandirse "hacia la derecha", como en este ejemplo de los CDs, nos da una pista de que necesitamos dividir los datos en dos o ms tablas a las que luego podamos acceder de forma conjunta para obtener los datos que necesitemos. Mucha gente nueva en los sistemas de bases de datos relacionales no sabe en verdad lo que significa "relacional" en RDBMS (Relational Database Management System). En trmin os simples, grupos parecidos de informacin son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basndose en los datos que tengan en comn. Desafortunadamente esto suena bastante acadmico y vago, sin embargo, en nuestra base de datos de CDs podemos ejemplificar una situacin concreta en la que veremos cmo normalizar los datos. El darnos cuenta de que cada lista de CDs tiene un conjunto fijo de atributos (ttulo, artista, ao, gnero) y un conjunto variable de atributos (el nmero de pistas) nos da una idea de cmo dividir los datos en mltiples tablas que luego podamos relacionar entre s. Podemos crear una tabla que contenga una lista de todos los lbumes y sus atributos fijos y otra que contenga una lista de todas las pista de esos lbumes. De esta forma, en vez de pensar en forma horizontal (como con la hoja de clculo), pensamos en forma vertical y dejamos una estructura de tablas como la que se muestra a continuacin. CREATE TABLE album ( id_album INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, titulo VARCHAR(80) NOT NULL ); CREATE TABLE pista ( id_album INTEGER NOT NULL, numero titulo INTEGER NOT NULL, VARCHAR(80) NOT NULL );

El identificador de lbum (id_album) es lo que relaciona las distintas pistas de un lbum dado. El campo id_album en la tabla pista coincide con el campo id_album en la tabla album, de tal manera que para obtener una lista de todas las pistas de un lbum dado, podramos realizar una consult a como esta: SELECT pista.numero, pista.nombre FROM album, pista WHERE album.titulo = "El titulo del album" AND album.id_album = pista.id_album Esta estructura es a la vez flexible y eficiente. La flexibilidad est en el hecho que podemos agregar datos al sistema posteriormente sin tener que rescribir lo que ya tenemos. Por ejemplo, si quisiramos agregar la informacin de los artistas de cada lbum, lo nico que tenemos que hacer es crear una tabla artista que est relacionada a la tabla album de la misma manera que la tabla pista. Por lo tanto, no

tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar la que hace falta. La eficiencia se refiere al hecho de que no tenemos duplicacin de datos, y tampoco tenemos grandes cantidades de "celdas vacas". De esta manera MySQL no tiene que almacenar ms datos de los necesarios, ni gastar recursos al revisar las reas vacas en nuestras tablas. El objetivo principal del diseo de bases de datos es generar tablas que modelan los regist ros en los que guardaremos nuestra informacin. Es importante que esta informacin se almacene sin redundancia para que se pueda tener una recuperacin rpida y eficiente de los datos. A travs de la normalizacin tratamos de evitar ciertos defectos que no s conduzcan a un mal diseo y que lleven a un procesamiento menos eficaz de los datos. Podramos decir que estos son los principales objetivos de la normalizacin: Controlar la redundancia de la informacin. Evitar prdidas de informacin. Capacidad para representar toda la informacin. Mantener la consistencia de los datos.

Si somos novatos en el ambiente de las bases de datos relacionales pudiramos pensar que con la normalizacin nuestros datos tienen una apariencia extraa, sin embargo, esto le permite a MySQL ser muy eficiente al momento de almacenar y recuperar los datos de las tablas, adems de que nos da la flexibilidad de crecer y escalar nuestras aplicaciones sin la necesidad de reestructurar una base de datos a cada momento. Seleccionar el tipo de dato apropiado Una vez identificadas todas las tablas y columnas que necesita la base de datos, debemos determinar el tipo de dato de cada campo. Existen tres categoras principales que pueden aplicarse prcticamente a cualquier aplicacin de bases de datos: Texto Nmeros Fecha y hora

Cada uno de stos presenta sus propias variantes, por lo que la eleccin del tipo de dato correcto no slo influye en el tipo de informacin que se puede almacenar en cada campo, sino que afecta al rendimiento global de la base de datos. A continuacin se dan algunos consejos que nos ayudarn a elegir un tipo de dato adecuado para nuestras tablas: Identificar si una columna debe ser de tipo texto, numrico o de fecha. Esto suele ser un paso demasiado sencillo. Valores eminentemente numricos como cdigos postales o cantidades monetarias deben tratarse como campos de texto si decidimos incluir sus signos de puntuacin, pero obtendremos mejores resultados si los almacenamos como nmeros y solucionamos la cuestin del formato d e alguna otra forma. Elegir el subtipo ms apropiado para cada columna. Los campos de longitud fija (como CHAR) son generalmente ms rpidos que los de longitud variable (como VARCHAR), aunque ocupan ms espacio en disco.

El tamao de cada campo debe restringirse al mnimo en funcin de cul pudiera ser la entrada ms grande. Por ejemplo, si el valor en una columna de tipo entero es menor de mil, lo mejor es configurar esta columna como un SMALLINT de tres dgitos sin signo (lo que permite exactamente 999 valores distintos). Configurar la longitud mxima para las columnas de texto y numricas, as como otros atributos. Puede que nosotros tengamos preferencias distintas, pero el factor ms importante es siempre ajustar al mximo la informacin de cada campo en lugar de usar siempre tipos TEXT e INT genricos (e ineficientes). Utilizar ndices apropiadamente Los ndices son un sistema especial que utilizan las bases de datos para mejorar su rendimiento global. Al definir ndices en las columnas de una tabla, se le indica a MySQL que preste atencin especial a dichas columnas. MySQL permite definir hasta 32 ndices por cada tabla y cada ndice puede incorporar hasta 16 columnas. Aunque un ndice de varias columnas puede no resultar de utilidad obvia a primera vista, lo cierto es que resulta muy til a la hora de realizar bsquedas fr ecuentes sobre un mismo conjunto de columnas. Dado que los ndices hacen que las consultas se ejecuten ms rpido, podemos estar incitados a indexar todas las columnas de nuestras tablas. Sin embargo, lo que tenemos que saber es que el usar ndices tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, MySQL tiene que actualizar cualquier ndice en la tabla para reflejar los cambios en los datos. As que, cmo decidimos usar ndices o no?. La respuesta es "depende". De manera simple, depende que tipo de consultas ejecutamos y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas. La razn para tener un ndice en una columna es para permitirle a MySQL que ejecute las bsquedas tan rpido como sea posible (y evitar los escaneos completos de tablas). Podemos pensar que un ndice contiene una entrada por cada valor nico en la columna. En el ndice, MySQL debe contar cualquier valor duplicado. Estos valores duplicados decrementan la eficiencia y la utilidad del ndice. As que antes de indexar una columna, debemos considerar que porcentaje de entradas en la tabla son duplicadas. Si el porcentaje es demasiado alto, seguramente no veremos alguna mejora con el uso de un ndice. Otra cosa a considerar es qu tan frecuentemente los ndices sern usados. MySQL puede usar un ndice para una columna en particular si dicha columna aparece en la clusula WHERE en una consulta. Si muy rara vez usamos una columna en una clusula WHERE, seguramente no tiene mucha sentido indexar dicha columna. De esta manera, probablemente sea ms eficiente sufrir el escaneo completo de la tabla las raras ocasiones en que se use esta columna en una consulta, que estar actualizando el ndice cada vez que cambien los datos de la tabla. Ante la duda, no tenemos otra alternativa que probar. Siempre podemos ejecutar algunas pruebas sobre los datos de nuestras tablas con y sin ndices para ver como obtenemos los resultados ms rpidamente. Lo nico a considerar es que las pruebas sean lo ms realistas posibles. Usar consultas REPLACE

Existen ocasiones en las que deseamos insertar un registro a menos de que ste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiramos hacer es una actualizacin de los datos. En lugar de escribir el cdigo que cumpla con esta lgica, y tener que ejecutar varias consultas, lo mejor es usar la sentencia REPLACE de MySQL. Usar tablas temporales Cuando estamos trabajando con tablas muy grandes, suele suceder que ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeo subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas sobre la tabla completa y hacer que MySQL encuentre cada vez los pocos registros que necesitamos, puede ser mucho ms rpido seleccionar dic hos registros en una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla. Crear una tabla temporal es tan sencillo como agregar la palabra TEMPORARY a una sentencia tpica CREATE TABLE: CREATE TEMPORARY TABLE tabla_temp ( campo1 tipoDato, campo2 tipoDeDato, ... ); Una tabla temporal existe mientras dure la conexin a MySQL. Cuando se interrumpe la conexin MySQL remueve automticamente la tabla y libera el espacio que sta usaba. Nosotros podemos por supuesto eliminar esta tabla mientras estamos conectados a MySQL. Si una tabla nombrada tabla_temp ya existe en nuestra base de datos al momento de crear una tabla temporal con el mismo nombre, la tabla temporal oculta a la tabla no temporal. MySQL tambin permite especificar que una tabla temporal sea creada en memoria si dicha tabla se declara del tipo HEAP: CREATE TEMPORARY TABLE tabla_temp ( campo1 tipoDato, campo2 tipoDeDato, ... ) TYPE = HEAP; Ya que las tablas del tipo HEAP son almacenadas en memoria, las consultas sobre estas tablas son ejecutadas mucho ms rpido que en las tablas en disco no temporales. Sin embargo las tablas HEAP son ligeramente diferentes de una tabla normal y tienen algunas limitaciones propias. Como en las sugerencias previas, lo nico que nos queda es probar si con las tablas temporales nuestras consultas se ejecutan ms rpidamente que usando la tabla que contiene una gran cantidad de datos. Si los datos estn bien indexados puede que las tablas temporales no nos sean de mucha utilidad. Usar una versin reciente de MySQL La recomendacin es simple y concreta, siempre que est en nuestras manos, debemos usar la versin ms reciente de MySQL que se encuentre disponible. Adems de que las nuevas versiones frecuentemente incluyen muchas mejoras, cada vez son ms estables y ms rpidas. De esta manera, a

la vez que sacamos provecho de las nuevas caractersticas incorporadas en MySQL, veremos significativos incrementos en la eficiencia de nuestro servidor de bases de datos. Consideraciones finales El ltimo paso del diseo de la base de datos es adoptar determinadas convenciones de nombres. Aunque MySQL es muy flexible en cuanto a la forma de asignar nombre a las bases de datos, tablas y columnas, he aqu algunas reglas que es conveniente observar: Utilizar caracteres alfanumricos. Limitar los nombres a menos de 64 caracteres (es una restriccin de MySQL). Utilizar el guin bajo (_) para separar palabras. Utilizar palabras en minsculas (esto es ms una preferencia personal que una regla). Los nombres de las tablas deberan ir en plural y los nombres de las columnas en singular (es igual una preferencia personal). Utilizar las letras ID en las columnas de clave primaria y fornea. En una tabla, colocar primero la clave primaria seguida de las claves forneas. Los nombres de los campos deben ser descriptivos de su contenido. Los nombres de los campos deben ser unvocos entre tablas, excepcin hecha de las claves.

Los puntos anteriores corresponden muchos de ellos a preferencias personales, ms que a reglas que debamos de cumplir, y en consecuencia muchos de ellos pueden ser pasados por alto, sin embargo, lo ms importante es que la nomenclatura utilizada en nuestras bases de datos sea coherente y consistente con el fin de minimizar la posibilidad de errores al momento de crear una aplicacin de bases de datos. Tipos de base de datos Las bases de datos pueden clasificarse de varias maneras, de acuerdo al contexto que se est manejando, la utilidad de las mismas o las necesidades que satisfagan. [editar]Segn la variabilidad de los datos almacenados [editar]Bases de datos estticas Son bases de datos de slo lectura, utilizadas primordialmente para almacenar datos histricos que posteriormente se pueden utilizar para estudiar el comportamiento de un conjunto de datos a travs del tiempo, realizar proyecciones, tomar decisiones y realizar anlisis de datos para inteligencia empresarial. [editar]Bases de datos dinmicas stas son bases de datos donde la informacin almacenada se modifica con el tiempo, permitiendo operaciones como actualizacin, borrado y adicin de datos, adems de las operaciones fundamentales de consulta. Un ejemplo de esto puede ser la base de datos utilizada en un sistema de informacin de un supermercado, una farmacia, un videoclub o una empresa. [editar]Segn el contenido [editar]Bases de datos bibliogrficas Slo contienen un subrogante (representante) de la fuente primaria, que perm ite localizarla. Un registro tpico de una base de datos bibliogrfica contiene informacin sobre el autor, fecha de publicacin, editorial, ttulo, edicin, de una determinada publicacin, etc. Puede contener un resumen o extracto de la publicacin original, pero nunca el texto completo, porque si no, estaramos en presencia de una base

de datos a texto completo (o de fuentes primarias ver ms abajo). Como su nombre lo indica, el contenido son cifras o nmeros. Por ejemplo, una coleccin de resultados de anlisis de laboratorio, entre otras. [editar]Bases de datos de texto completo Almacenan las fuentes primarias, como por ejemplo, todo el contenido de todas las ediciones de una coleccin de revistas cientficas. [editar]Directorios Un ejemplo son las guas telefnicas en formato electrnico. [editar]Bases de datos o "bibliotecas" de informacin qumica o biolgica Son bases de datos que almacenan diferentes tipos de informacin proveniente de la qumica, las ciencias de la vida o mdicas. Se pueden considerar en varios subtipos: Las que almacenan secuencias de nucletidos o protenas. Las bases de datos de rutas metablicas. Bases de datos de estructura, comprende los registros de datos experimentales sobre estructuras 3D de biomolculasBases de datos clnicas. Bases de datos bibliogrficas (biolgicas, qumicas, mdicas y de otros campos): PubChem, Medline, EBSCOhost.