Ejemplos de conexión con bases de datos Access.docx

Ejemplos de conexión con bases de datos Access

Recuerde que sólo podrá conectar a bases de datos de Access si tiene contratado un Plan de Alojamiento bajo sistema operativo Windows.

Usando ASP (en VBScript) y ADO

Para acceder a una base de datos mediante DSN tendrá que crear dicho DSN para su Plan de Alojamiento.

En el ejemplo que sigue asumimos, para el acceso mediante DSN, que el mismo se llama dominio.com.DSNAccess

<%Option Explicit

'Se declaran las variablesDim ConexionDim CadenaDim RutafisicaDim ADOPersonasDim MiIdDim MiNombre

'Se crean dos objetos, una conexión y un recordsetSet Conexion = CreateObject("ADODB.Connection")Set ADOPersonas = CreateObject("ADODB.Recordset")

'Se establece la cadena de conexión.'Hay que elegir una de las dos opciones:

'1)----Código para acceder mediante un DSN----Cadena="DSN=dominio.com.DSNAccess"

'2)----Código para acceder utilizando cadena de conexión----'Consulte la ruta física a la raíz de su dominio en el servidor.'Los parámetros UID y PWD son opcionales.Rutafisica="unidad:\rutadirectorios"Cadena="Driver={Microsoft Access Driver (*.mdb)};DBQ=" & Rutafisica &"\data\DBPersonas.mdb;UID=usuario;PWD=pwd;"

'Se abre la conexiónConexion.Open Cadena

'Se ejecuta la sentencia SQLADOPersonas.Open "Select Id, Nombre from Personas", Conexion%>

<HTML><HEAD> <TITLE>Resultado</TITLE></HEAD><BODY> <h2><center>Ejemplo de conexión a Access con ASP-VBScript</center></h2> <table width="30%" border="1" align="center"> <tr> <td><center><b>Id</b></center></td> <td><center><b>Nombre</b></center></td> </tr><%

'Se recorre la tabla y se muestran los resultadosWhile Not ADOPersonas.eof Set MiId=ADOPersonas("Id") Set MiNombre=ADOPersonas("Nombre")%>

<tr> <td><%=MiId%></td> <td><%=MiNombre%></td> </tr>

<% ADOPersonas.MovenextWend

'Se cierran el Recordset y la conexiónADOPersonas.CloseConexion.Close%>

</BODY></HTML>

Usando PERL y ADO



Tenga en cuenta que los archivos en PERL sobre Windows suelen tener la extensión .pl ó .cgi

Se puede acceder a la base de datos utilizando el método Execute sobre una conexión, o creando un objeto Recordset. Veamos un ejemplo de cada caso:

Ejemplo usando el método Execute:

use strict;use Win32::OLE;

#Se imprimen las cabecerasprint "HTTP/1.0 200 OK\n";print "Content-type: text/html\n\n";

print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a Access con script de Perl usando ADO</center></h2>";print "<PRE>\n";

#Se crea un objeto conexiónmy $MiConexion = Win32::OLE->new("ADODB.Connection");

#Se establece la cadena de conexión.#Hay que elegir una de las dos opciones:

#1------Código para acceder mediante un DSN------my $Cadena="DSN=dominio.com.DSNAccess";

#2------Código para acceder utilizando cadena de conexión------#El campo DBQ será la ruta y nombre de nuestra base de datos#Los campos UID y PWD son el usuario y contraseña si existen#IMPORTANTE: $rutafisica contiene la ruta física en disco a la#raíz de su dominio en el servidor. Consulte este dato para acceder#por este método.my $rutafisica="unidad:\\rutadirectorios";my $Cadena="Driver={Microsoft Access Driver (*.mdb)};DBQ=$rutafisica\\data\\DBPersonas.mdb;UID=;PWD=;";

#Se conecta con la base de datos$MiConexion->Open($Cadena);

#Se ejecuta la consulta SQLmy $RS = $MiConexion->Execute("SELECT * FROM Personas");

#Se recorre la tabla y se imprimen los datoswhile ( !$RS->EOF ) { my $Id = $RS->Fields('Id')->value;

my $Nombre = $RS->Fields('Nombre')->value; print "$Id\t$Nombre\n"; $RS->MoveNext;}

#Para finalizar se cierra la conexión$MiConexion->Close;

#Y escribimos las cabeceras de finalizaciónprint "</PRE>\n";print "</BODY>\n";print "</HTML>\n";

Ejemplo usando un objeto Recordset:



print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a Access con script Perl usando ADO</center></h2>";print "<PRE>\n";

#Se crean un objeto conexión y un objeto Recordsetmy $MiConexion = Win32::OLE->new("ADODB.Connection");my $ADOPersonas= Win32::OLE->new("ADODB.Recordset");


#1------Código para acceder mediante un DSN------my $Cadena="DSN=dominio.com.DSNAccess";

#2------Código para acceder utilizando cadena de conexión------#El campo DBQ será la ruta y nombre de nuestra base de datos#Los campos UID y PWD son el usuario y contraseña si existen#IMPORTANTE: $rutafisica contiene la ruta física en disco a la#raíz de su dominio en el servidor. Consulte este dato para acceder#por este método.my $rutafisica="unidad:\\rutadirectorios";my $Cadena="Driver={Microsoft Access Driver (*.mdb)};

DBQ=$rutafisica\\data\\DBPersonas.mdb;UID=;PWD=;";

#Se abre la conexión con la base de datos$MiConexion->Open($Cadena);$ADOPersonas->open("select Id, Nombre from Personas",$MiConexion,3, 3);

#Se recorre la tabla y se imprimen los datoswhile ( not $ADOPersonas->{EOF}){ my $Id = $ADOPersonas->{'Id'}->Value; my $Nombre = $ADOPersonas->{'Nombre'}->Value; print "$Id\t$Nombre\n"; $ADOPersonas->{MoveNext};}

#Se cierran el Recordset y la conexión$ADOPersonas->Close;$MiConexion->Close;

#Y escribimos las cabeceras de finalizaciónprint "</PRE>\n";print "</BODY>\n";print "</HTML>\n";

Usando PERL y DBI



Tenga en cuenta que los archivos en PERL sobre Windows deben tener la extensión .pl ó .cgi

use strict;use DBI;


print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a Access con script de Perl</center></h2>";print "<PRE>";


#1------Código para acceder mediante un DSN------my $Cadena="dominio.com.DSNAccess";

#2------Código para acceder utilizando cadena de conexión------#El campo DBQ será la ruta y nombre de nuestra base de datos#Los campos UID y PWD son el usuario y contraseña si existen#IMPORTANTE: $rutafisica contiene la ruta física en disco a la#raíz de su dominio en el servidor. Consulte este dato para acceder#por este método.my $rutafisica="unidad:\\rutadirectorios";my $Cadena="Driver={Microsoft Access Driver (*.mdb)};DBQ=$rutafisica\\data\\DBPersonas.mdb;UID=;PWD=;";

#Se abre una conexión con la base de datosmy $dbh=DBI->connect("dbi:ODBC:$Cadena");

#Se define la consultamy $SQL= "SELECT Id, Nombre FROM Personas";

#Se prepara y ejecuta la sentencia.#Si se produce algún error el programa finalizamy $sth = $dbh->prepare($SQL) ordie "No puedo conectar a la base de datos";$sth->execute;

#Se recorre la tabla y se muestran los datosprint "Id\tNombre\n";while (my $ref = $sth->fetchrow_arrayref) { print "$ref->[0]\t$ref->[1]\n";}

#Se desconecta de la base de datos$sth->finish();$dbh->disconnect();

#Y escribimos las cabeceras de finalizaciónprint "</PRE>";print "</BODY>\n";print "</HTML>\n";

Ejemplos de conexión con bases de datos SQL Server

Recuerde que sólo podrá conectar a bases de datos de SQL Server si tiene contratado un Plan de Alojamiento Web bajo sistema operativo Windows.

En este apartado podrá ver ejemplos de distintas formas de conectar con una base de datos de SQL Server para realizar una sencilla consulta de selección. Consulte la documentación de SQL Server y ADO para ejecutar sentencias más complejas, procedimientos almacenados, etc.

Usando ASP (en VBScript) y ADO

<%Option Explicit

'Se declaran las variablesDim ConexionDim CadenaDim ADOPersonasDim MiIdDim MiNombre

'Se crean dos objetos, una conexión y un RecordsetSet Conexion = CreateObject("ADODB.Connection")Set ADOPersonas = CreateObject("ADODB.Recordset")

'Se establece la cadena de conexión.'Hay que elegir una de las dos opciones:

'1)----Código para acceder mediante un DSN----Cadena="DSN=dominio.com.DSNSQLServer;UID=usuario;PWD=password"

'2)----Código para acceder utilizando cadena de conexión----'Establecemos la cadena de conexión.'El campo server será el servidor de SQL Server.'Database será el nombre de la base de datos.'uid es el nombre de usuario.'pwd es la contraseña.'Puede consultar todos estos datos en su panel de controlCadena="driver={SQL Server}; server=servidor; database=DBPersonas;uid=usuario; pwd=password"

'Se abre la conexiónConexion.Open CadenaADOPersonas.Open "Select Id, nombre from Personas", Conexion%>

<HTML><HEAD><TITLE>Resultado</TITLE></HEAD><BODY><h2><center>Ejemplo de conexión a SQLServer con ASP-VBScript</center></h2><table width="30%" border="1" align="center">

<tr> <td><center><b>Id</b></center></td> <td><center><b>Nombre</b></center></td> </tr>

<%'Se recorre la tabla y se muestran los resultadosWhile Not ADOPersonas.eof Set MiId=ADOPersonas("Id") Set MiNombre=ADOPersonas("Nombre")%>

<tr> <td><%=MiId%></td> <td><%=MiNombre%></td> </tr>


'Se cierran el recordset y la conexiónADOPersonas.CloseConexion.Close%>

</BODY></HTML>

Usando PERL y ADO


En el ejemplo que sigue asumimos, para el caso de acceso por DSN, que el mismo se llama dominio.com.DSNSQLServer.


Ejemplo con sentencia Execute:



print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";

print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a SQLServer con script Perl usando ADO</center></h2>";print "<PRE>\n";

#Se abre una conexión con la base de datosmy $MiConexion = Win32::OLE->new("ADODB.Connection");


#1------Código para acceder mediante un DSN------my $Cadena="DSN=dominio.com.DSNSQLServer;UID=usuario;PWD=password";

#2------Código para acceder utilizando cadena de conexión------#Consulte los datos de su base de datos SQL Server en el panel de controlmy ($servidor, $bd, $usuario, $passw)='servidor', 'DBPersonas', 'usuario', 'password');my $Cadena="driver={SQL Server}; server=$servidor; database=$bd;uid=$usuario; pwd=$passw";



#Se recorre la tabla y se imprimen los datoswhile ( !$RS->EOF ) { my $Id = $RS->Fields('Id')->value; my $Nombre = $RS->Fields('Nombre')->value; print "$Id\t$Nombre\n"; $RS->MoveNext;}

#Se cierra la conexión$MiConexion->Close;

#Se imprimen las cabeceras de finalizaciónprint "</PRE>\n";print "</BODY>\n";print "</HTML>\n";

Ejemplo con el objeto Recordset:



print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a SQLServer con script Perl usando ADO</center></h2>";print "<PRE>\n";

#Se crean los objetos conexión y Recordsetmy $MiConexion = Win32::OLE->new("ADODB.Connection");my $ADOPersonas= Win32::OLE->new("ADODB.Recordset");



#2------Código para acceder utilizando cadena de conexión------#Consulte los datos de su base de datos SQL Server en el panel de controlmy ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $Cadena="driver={SQL Server}; server=$servidor; database=$bd;uid=$usuario; pwd=$passw";

#Se abre la conexión con la base de datos$MiConexion->Open($Cadena);$ADOPersonas->open("select Id, Nombre from Personas",$MiConexion,3, 3);


#Se cierran el Recordset y la conexión$ADOPersonas->Close;$MiConexion->Close;

#Se imprimen las cabeceras de finalizaciónprint "</PRE>\n";print "</BODY>\n";

print "</HTML>\n";

Usando PERL y DBI


En el ejemplo que sigue asumimos, para el caso de acceso con DSN, que el mismo se llama dominio.com.DSNSQLServer.


use strict;use DBI;


print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a SQLServer con script de Perl</center></h2>";print "<PRE>";



#2------Código para acceder utilizando cadena de conexión------#Consulte los datos de la base de datos SQL Server en el panel de controlmy ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'pass');my $Cadena="driver={SQL Server}; server=$servidor; database=$bd;uid=$usuario; pwd=$passw";

#Se abre una conexión con la base de datos.my $dbh=DBI->connect("dbi:ODBC:$Cadena");

#Se define la consultamy $SQL= "SELECT Id, Nombre FROM Personas";

#Se prepara y ejecuta la sentencia.#Si se produce algún error el programa finaliza

my $sth = $dbh->prepare($SQL) ordie "No puedo conectar a la base de datos";$sth->execute;



#Se imprimen las cabeceras de finprint "</PRE>";print "</BODY>\n";print "</HTML>\n";

Ejemplos de conexión con bases de datos MySQL

Podrá conectar con bases de datos MySQL tanto si tiene contratado un Plan de Alojamiento Web bajo sistema operativo Windows o Linux.

Utilizando ASP (en VBScript) y ADO

<%Option Explicit


'Se crean los objetos conexión y RecordsetSet Conexion = CreateObject("ADODB.Connection")Set ADOPersonas = CreateObject("ADODB.Recordset")

'Se establece la cadena de conexión'El campo server será el servidor de MySQL'Database será el nombre de la base de datos'uid es el nombre de usuario'pwd es la contraseña'Puede consultar todos estos datos en su panel de controlCadena="Driver={mySQL}; Server=servidor; Database=DBPersonas;Uid=usuario; Pwd=password"


'IMPORTANTE: MySQL es sensible a mayúsculas/minúsculas en las consultas SQL'Esto quiere decir que las tablas "Personas" y "personas" son distintas.ADOPersonas.Open "Select Id, Nombre from Personas", Conexion%>

<HTML><HEAD><TITLE>Resultado</TITLE></HEAD><BODY><h2><center>Ejemplo de conexión a MySQL con ASP-VBScript</center></h2><table width="30%" border="1" align="center"><tr> <td><center><b>Id</b></center></td> <td><center><b>Nombre</b></center></td></tr>

<%' Se recorre la tabla y se muestran los resultadosWhile Not ADOPersonas.eof Set MiId=ADOPersonas("Id") Set MiNombre=ADOPersonas("Nombre")%>

<tr> <td><%=MiId%></td> <td><%=MiNombre%></td></tr>


'Se cierran los objetos creadosADOPersonas.CloseConexion.Close%>

</BODY></HTML>

Utilizando PERL y ADO




print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a MySQL con script de Perl usando ADO</center></h2>";print "<PRE>\n";

#Se crea el objeto conexiónmy $MiConexion = Win32::OLE->new("ADODB.Connection");

#Se establece la cadena de conexión#Consulte los datos de la conexión en el panel de controlmy ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $Cadena="driver={MySQL}; server=$servidor; database=$bd;uid=$usuario; pwd=$passw";


#Se ejecuta la consulta SQL#IMPORTANTE: MySQL es sensible a mayúsculas/minúsculas en las consultas SQL.#Esto quiere decir que las tablas "Personas" y "personas" son distintas.my $RS = $MiConexion->Execute("SELECT * FROM Personas");



#Se imprimen las cabeceras de finprint "</PRE>\n";print "</BODY>\n";print "</HTML>\n";

Ejemplo usando el objeto Recordset:



print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a MySQL con script de Perl usando ADO</center></h2>";print "<PRE>\n";


#Se establece la cadena de conexión.#Consulte los datos de la conexión en el panel de control.my ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $Cadena="driver={MySQL}; server=$servidor; database=$bd;uid=$usuario; pwd=$passw";

#Se abre la conexión con la base de datos$MiConexion->Open($Cadena);

#Se realiza la consulta SQL#IMPORTANTE: MySQL es sensible a mayúsculas/minúsculas en las consultas SQL.#Esto quiere decir que las tablas "Personas" y "personas" son distintas.$ADOPersonas->open("select Id, Nombre from Personas",$MiConexion,3, 3);


#Se cierran los objetos creados$ADOPersonas->Close;

$MiConexion->Close;


Utilizando PERL y DBI

use strict;use DBI;


print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a MySQL con script de Perl usando DBI</center></h2>";print "<PRE>";

#Se establece la cadena de conexión#Consulte los datos de la conexión en el panel de controlmy ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $cadena="DBI:mysql:database=$bd;host=$servidor";

#Se conecta a la base de datosmy $dbh = DBI->connect($cadena,$usuario,$passw);

#Se realiza la consulta SQL#IMPORTANTE: MySQL es sensible a mayúsculas/minúsculas en las consultas SQL.#Esto quiere decir que las tablas "Personas" y "personas" son distintas.my $SQL= "SELECT Id, Nombre FROM Personas";my $sth = $dbh->prepare($SQL) ordie "No puedo conectar a la base de datos";$sth->execute;



#Se escriben las cabeceras de finprint "</PRE>";print "</BODY>\n";print "</HTML>\n";


#!/usr/bin/perl

use DBI();

#Se imprimen las cabecerasprint "content-type: text/html\n\n";

print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a MySQL con script de Perl</center></h2>";print "<PRE>";

#Se establece la cadena de conexión.#Consulte los datos de la conexión en el panel de controlmy ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $cadena="DBI:mysql:dbname=$bd; host=$servidor";

#Se realiza la conexiónmy $dbh = DBI->connect($cadena,$usuario,$passw);

#Se ejecuta la consulta SQL#IMPORTANTE: MySQL es sensible a mayúsculas/minúsculas en las consultas SQL.#Esto quiere decir que las tablas "Personas" y "personas" son distintas.my $SQL= "SELECT Id, Nombre FROM Personas";my $sth = $dbh->prepare($SQL) or die "No puedo conectar a la base de datos";$sth->execute;

#Se recorre la tabla y se muestran los datosprint "Id\tNombre\n";while (my $ref = $sth->fetchrow_arrayref) { print "$ref->[0]\t$ref->[1]\n";

}



Utilizando PHP

<html><body>

<?php#Se efectúa la conexión usando 3 parámetros#(servidor, usuario y contraseña)#Consulte estos datos en el panel de control$db = mysql_connect("servidor", "usuario", "password");

#Se selecciona la base de datos que se va a utilizarmysql_select_db("DBPersonas",$db);

#Se ejecuta una consulta SQL$result = mysql_query("SELECT * FROM Personas",$db);

echo "<table border=1>\n";echo "<tr><td>Id</td><td>Nombre</td></tr>\n";

#Se recorre el resultado mostrando la informaciónwhile ($myrow = mysql_fetch_row($result)) { printf("<tr><td>%s</td><td>%s</td></tr>\n",$myrow[0],$myrow[1]);}

echo "</table>\n";?>

</body></html>

Ejemplos de conexión con bases de datos PostgreSQL

Utilizando ASP (en VBScript) y ADO

<%

Option Explicit


'Se crean los objetos conexión y RecordsetSet Conexion = CreateObject("ADODB.Connection")Set ADOPersonas = CreateObject("ADODB.Recordset")

'Se establece la cadena de conexión'El campo server será el servidor de PostgreSQL'Database será el nombre de la base de datos'uid es el nombre de usuario

'pwd es la contraseña'Puede consultar todos estos datos en su panel de controlCadena="Driver={PostgreSQL}; Server=servidor; Database=DBPersonas;Uid=usuario; Pwd=password"


'Se realiza la consulta SQLADOPersonas.Open "Select Id, Nombre from Personas", Conexion%>

<HTML><HEAD><TITLE>Resultado</TITLE></HEAD><BODY><h2><center>Ejemplo de conexión a PostgreSQL con ASP-VBScript</center></h2><table width="30%" border="1" align="center"><tr> <td><center><b>Id</b></center></td> <td><center><b>Nombre</b></center></td></tr>

<%'Se recorre la tabla y se muestran los resultadosWhile Not ADOPersonas.eof Set MiId=ADOPersonas("Id") Set MiNombre=ADOPersonas("Nombre")%>

<tr> <td><%=MiId%></td> <td><%=MiNombre%></td></tr>


'Se cierran los objetos creadosADOPersonas.CloseConexion.Close%>

</BODY></HTML>

Utilizando PERL y ADO




print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a PostgreSQL con script de Perl usando ADO</center></h2>";print "<PRE>\n";

#Se crea el objeto conexiónmy $MiConexion = Win32::OLE->new("ADODB.Connection");

#Se establece la cadena de conexión#Consulte los datos de la conexión en el panel de controlmy ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $Cadena="driver={PostgreSQL}; server=$servidor; database=$bd;uid=$usuario; pwd=$passw";






Ejemplo usando el objeto Recordset:



print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a PostgreSQL con script de Perl usando ADO</center></h2>";print "<PRE>\n";


#Se establece la cadena de conexión.#Consulte los datos de la conexión en el panel de control.my ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $Cadena="driver={PostgreSQL}; server=$servidor; database=$bd;uid=$usuario; pwd=$passw";

#Se abre la conexión con la base de datos$MiConexion->Open($Cadena);

#Se realiza la consulta SQL$ADOPersonas->open("select Id, Nombre from Personas",$MiConexion,3, 3);

#Se recorre la tabla y se imprimen los datoswhile ( not $ADOPersonas->{EOF}){ my $Id = $ADOPersonas->{'Id'}->Value; my $Nombre = $ADOPersonas->{'Nombre'}->Value; print "$Id\t$Nombre\n"; $ADOPersonas->{MoveNext};

}

#Se cierran los objetos creados$ADOPersonas->Close;$MiConexion->Close;



use strict;use DBI;


print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a PostgreSQL con script de Perl usando DBI</center></h2>";print "<PRE>";

#Se establece la cadena de conexión#Consulte los datos de la conexión en el panel de controlmy ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $cadena="DBI:PgPP:database=$bd;host=$servidor";

#Se conecta a la base de datosmy $dbh = DBI->connect($cadena, $usuario, $passw);

#Se realiza la consulta SQLmy $SQL= "SELECT Id, Nombre FROM Personas";my $sth = $dbh->prepare($SQL) ordie "No puedo conectar a la base de datos";$sth->execute;





#!/usr/bin/perl

use DBI();

#Se imprimen las cabecerasprint "content-type: text/html\n\n";

print "<HTML>\n";print "<HEAD>\n";print "<TITLE>Resultado</TITLE>\n";print "</HEAD>\n";print "<BODY>\n";print "<h2><center>Ejemplo de conexión a PostgreSQL con script de Perl</center></h2>";print "<PRE>";

#Se establece la cadena de conexión.#Consulte los datos de la conexión en el panel de controlmy ($servidor, $bd, $usuario, $passw) =('servidor', 'DBPersonas', 'usuario', 'password');my $cadena="DBI:Pg:dbname=$bd; host=$servidor";

#Se realiza la conexión

my $dbh = DBI->connect($cadena, $usuario, $passw);

#Se ejecuta la consulta SQLmy $SQL= "SELECT Id, Nombre FROM Personas";my $sth = $dbh->prepare($SQL) ordie "No puedo conectar a la base de datos";$sth->execute;




Utilizando PHP

<html><body>

<?php

#Se establece la cadena de conexión#Consulte los datos de acceso de su base de datos en su panel de control$cadena = "host=servidor port=5432 dbname=DBPersonas user=usuariopassword=contraseña";

#Se efectua la conexión$connection = pg_pconnect ($cadena);

#Se ejecuta la consulta$result=pg_exec("SELECT * FROM Personas");

#Mostramos los resultadosprint "Id , Nombre\n";$rows = pg_numrows($result);for ($i=0; $i < $rows; $i++){ list($foo,$bar) = pg_fetch_row($result,$i); print "($foo , $bar)\n";}

#Se cierra la conexiónpg_close($connection);?>

</body></html>

Diagramas entidad-relación y de clases de UML

en el modelado de gobierno electrónico

Jesus Alberto Andrade CastroLaboratorio de Investigación de Tecnologías y Sistemas de Información,

Computación, Universidad Del Zulia. Maracaibo, Zulia. República Bolivariana de Venezuela

[email protected]

ResumenEl Lenguaje de Modelado Unificado (UML) es considerado hoy en día un método estándar para el desarrollo de sistemas de información. Sin embargo, el grado de fiabilidad y flexibilidad de los portales de gobierno electrónico, requieren el uso de principios básicos y del concurso y la experiencia de viejos estilos y disciplinas del desarrollo de sistemas, que sean independientes de los softwares de aplicación disponibles en el mercado. En ello, el modelo Entidad Relación (ER) es una herramienta fundamental para el modelado de trámites de e-gobierno porque son fácilmente transferidos a los diagramas de clases de UML. De manera que al modelar un sitio Web para gobierno electrónico con UML y ER, el sistema es dotado con diagramas gráficos semi-formales, que permiten el diseño de múltiples vistas basado en un modelado conceptual a partir de las instancias y requerimientos legales de la administración pública. Este trabajo analiza el uso del Modelo Entidad Relación y los diagramas de clase de UML y propone, en forma práctica, las notaciones básicas que se requieren en el desarrollo de un portal de e-gobierno.

Palabras Clave:

Modelado, e-gobierno, Lenguaje de Modelado Unificado , Modelo Entidad Relación, diagramas de clase

Entity-relationship diagrams and UML class modeling e-

government

AbstractThe Unified Modeling Language (UML) is now considered a standard method for developing information systems. However, the degree of reliability and flexibility of e-government portals, require the use of basic principles of competition and the experience of old styles and disciplines of the development of systems that are independent of application software available on the market. In it, the Entity Relationship Model (ER) is an essential tool for modeling e-government procedures because they are easily transferred to UML class diagrams. So to model a Web site for e-government with UML and ER, the system is equipped with semi-formal graphical charts, which allow the design of multiple views based on a conceptual modeling from the courts or the administration's legal requirements public. This paper analyzes the use of entity-relationship model and UML class diagrams and proposes a practical, basic notations required in the development of e-government portal.

Key-words:

, Modeling, e-government, Unified Modeling Language , Entity Relationship Model

IntroducciónCon la creciente presencia de instituciones gubernamentales en la Internet y la variedad de servicios disponibles, la frontera existente entre usuarios, empresas y gobierno ha venido desvaneciéndose; sin embargo, cada vez más, las aplicaciones automatizadas son más complejas y las transacciones son más dinámicas. La gente suele pensar en relación con el gobierno como una estructura burocracia jerárquica (Margetts, 2003) y las burocracias son a menudo criticadas por su rigidez, lo procedimental, la ineficiencia y la incapacidad de servir a los seres humanos (Ho, 2002). Pero con e-gobierno se ofrece una oportunidad para "crear una nueva modalidad en los servicios públicos con la esperanza de ofrecer un servicio modernizado, integrado y sin fisuras en relación con las necesidades de sus ciudadanos" (Silcock, 2001).

Usualmente, el diseño de sistemas se realiza bajo el enfoque de caja negra; perspectiva que obliga a los desarrolladores de software a concentrarse en cómo es la funcionalidad de los componentes. Es por ello que con frecuencia, los datos son tratados normalmente con software construidos ad hoc para

satisfacer requisitos específicos de las organizaciones. Desafortunadamente, enfoques como éste presentan muchos inconvenientes, porque los sistemas terminan por identificarse con una determinada plataforma o se comprometen con arquitecturas que son incompatibles, y en consecuencia, se generan códigos y sistemas difíciles de mantener y depurar. Por otro lado, existe la necesidad de estandarizar la migración de sistemas en uso, hacia aplicaciones de servicios web; y también, hay necesidad de innovar en diseños de nuevas metodologías con un enfoque integral, sistemático, que en la medida de lo posible sea automatizable y con un lenguaje que sea común, tanto para el desarrollo de nuevas aplicaciones como para el desarrollo de sistemas heredados dirigidos a servicios en red, para evitar de esta manera rediseñar o reescribir desde cero los sistemas que se heredan.

Como consecuencia, una meta de los diseñadores y desarrolladores de portales debería ser lograr que los sistemas adopten tecnologías estandarizadas que satisfagan las necesidades y expectativas de calidad que tienen los usuarios. Para ayudar a garantizar claridad, adaptabilidad e integración, los sistemas deben ser especificados a nivel conceptual, a nivel de los metamodelos, utilizando para ello lenguajes que la gente pueda comprender fácilmente, con el fin de obtener aplicaciones sensibles a los requisitos de calidad de los datos.

Los portales de la administración pública dependen de diseños apropiados y de la especificación de los diversos procesos informacionales, comunicacionales o transaccionales que son comunes en el dominio de aplicación, los cuales deben ser expresados en un lenguaje común para que funcionen en las plataformas heterogéneas disponibles en la Internet, de forma tal que, aun cuando los requisitos de los diversos ámbitos de la administración electrónica varíen, la especificación de los procesos deberán seguir los principios generales del diseño.

Para ello, es necesario codificar los modelos disponibles en una representación común, de modo que las distintas notaciones puedan intercambiar data y diseños usando herramientas propias de modelado. Se trata de describir de modo preciso el significado de cada uno de los componentes del sistema, mediante el uso de una herramienta apropiada como es el Modelo Entidad Relación (ER), y transferidos a un lenguaje común para los diseñadores de sistemas, como es el Lenguaje de Modelado Unificado (UML). Algunos autores como Cao, Bryant, Zhao, Burt, Gray, Raje, Olson y Auguston (2005) han referido a estas transferencias de notación de modelado como conversión y des-conversión . El concepto se refiere a la transformación de un modelo en una forma semántica común intermedia, que es reinterpretada en otro entorno o usada por otra herramienta de modelado.

En el presente trabajo describimos una aproximación de la evolución de las relaciones que se pueden dar para transformar una aplicación de un sistema (mundo real) de la administración pública venezolana a un modelo conceptual, centrándose en la construcción de diagramas necesarios usados para definir un sistema de una manera consistente.

ContextoDesde que la Internet estuvo a disposición del público, la aparición de portales electrónicos se ha multiplicado y los servicios Web asociados a los negocios se han hecho tan populares, que su proliferación refleja el advenimiento de un nuevo paradigma de software relacionado con el diseño de componentes en ambientes de redes. Con ello, el desarrollo de servicios red o servicios web es parte del nuevo paradigma del diseño de sistemas basados en componentes de software, donde la Internet actúa como el centro de distribución de información.

Hoy en día es muy común encontrar diversidad de software, lenguajes y todo tipo de sistemas y servicios sobre Internet. Por lo tanto, existe también una tendencia a estandarizar el desarrollo de aplicaciones con el concurso de metodologías y lenguajes abiertos. Ejemplo de ello es el código XML que corresponde a la descripción estándar de un lenguaje abierto, o el protocolo de transporte HTTP y otros sistemas de software que están disponibles para el desarrollo de aplicaciones, que se incorporan a la red, que luego son reutilizadas e integradas en entornos distribuidos a través de plataformas heterogéneas que abundan en la Internet.

Dada la homogeneidad de portales existentes en la Web, se pudiera pensar que ellos son desarrollados bajo un único enfoque o lineamiento, que es independiente de la orientación, destino o “funcionabilidad” del sistema. Sin embargo, según Hofreiter; Huemer; Liegl; Mosser; Schuster y Zapletal (2007) existe una distinción entre portales dedicados al gobierno electrónico y el resto, y ello es así debido a la diferencia que se produce en los servicios de información, comunicación y transacciones. Los servicios de información ofrecen contenido a los ciudadanos y empresas de una manera unidireccional. Los servicios de comunicación ofrecen contenido de información pero de una manera bidireccional, por lo tanto permiten la retroalimentación.

En el gobierno electrónico, los procesos de prestación de servicios a menudo son multi-funcionales, y cada vez más inter-agencia. Debido a esto, el desarrollo de sistemas orientados a los procesos de análisis tiene que ser un elemento central de los proyectos de gobierno electrónico. La mayoría de los servicios de administración electrónica en uso hoy en día están orientados a servicios de información o de comunicación; sin embargo, hay que destacar que estos dos tipos de servicios no imponen retos tecnológicos de grandes magnitudes. Por otro lado, los servicios transaccionales son más difíciles de implementar, porque deben permitir interactuar entre las diversas instituciones gubernamentales con el fin de ejecutar funciones oficiales. Un servicio transaccional entre una organización (empresas públicas o privadas, oficinas gubernamentales, ciudadanos, etc.) y una agencia de gobierno, requiere que se alineen interfaces y sistemas entre las entidades actuantes. En portales de e-gobierno, se deben considerar los requisitos legales en una forma muy bien definida, por ello, para que una operación de gobierno electrónico se pueda ejecutar, las políticas y directrices necesarias deben estar plenamente establecidas. De manera que

en ese contexto, alinear la política significa que las partes involucradas deben actuar en un área jurídica específica, que no deje lugar a dudas del alcance y afectación de las transacciones. De forma tal que, si un modelo es compartido entre los agentes actuantes, tiene que ser formalmente correcto, a fin de garantizar una comunicación clara en términos del dominio de modelado. Por lo tanto, antes de ejecutar una operación de gobierno electrónico se deben determinar las políticas y directrices legales necesarias para poder realizar las transacciones asociadas; con el fin de actuar en un área jurídica específica, bien definida y segura, que sea compartida entre los entes involucrados.

Uno de los principales objetivos en la composición de servicios Web es proporcionar un método para crear aplicaciones ejecutables. La Figura 1 nos permite comprender mejor el impacto que pudiera originar el desarrollo de un sistema de servicios transaccionales en un dominio de gobierno.

Figura 1 Dominio de servicios transaccionales en

e-gobierno

La visión del desarrollo de servicios y aplicaciones en el gobierno electrónico es la de permitir que los programas nos eximan de gran parte de la carga de la localización de recursos de la Web, que son relevantes para nuestras necesidades; tales como extracción, integración e indexación de la información contenida

en su interior. En el e-gobierno, la magnitud de los requisitos legales supedita la disponibilidad de los recurso de la Web y otros requisitos (principalmente los organizacionales y técnicos), pues es el estamento legal, la razón de ser de las transacciones de servicios asociadas al desarrollo de portales web en las instancias de gobierno. La alineación política, contractual y los intereses de los gobiernos en relación con los procesos de negocios definen el tipo de orientación entre un portal de e-gobierno y cualquier otro tipo de portal con servicios transaccionales.

El desarrollo de software usando técnicas de modelado antes de la implementación real de un sistema ofrece muchas ventajas, como la abstracción, la visualización, la independencia de la tecnología y la reutilización (Karetsos, Manouselis y Costopoulou, 2011), de allí la importancia de usar un mecanismo técnico pero sencillo que permita la transición los requerimientos en la construcción de un modelo operacional de un sistema de gobierno electrónico.

Notación de modelado de datosLa calidad de un portal de gobierno electrónico depende fundamentalmente de su diseño; por ello, los modeladores de sistemas con frecuencia ponen mayor interés en las relaciones que se establecen en el diseño que en su implementación. Una herramienta de análisis y modelado de bases de datos muy popular que ha ocupado gran notoriedad desde la década de los 70 es el modelo expresado en entidades y relaciones, una técnica estándar aceptada desde entonces en el diseño de sistemas.

Desde que Peter Chen (1976) propuso en 1976 el Modelo Entidad Relación (ER) se contó con una metodología formal pero sencilla para el análisis y diseño de sistemas de información y bases de datos. Desde entonces, el modelo ER se hizo muy popular, y hoy constituye una piedra angular en la ingeniería de software que sirve para la conversión y des-conversión de propuestas de sistemas. El modelo ER es un enfoque conceptual acerca de datos que define, de una manera simple, al mundo real a través de entidades y relaciones, que permite diseñar una base de datos bajo un esquema de alto nivel conceptual, sin considerar los problemas de bajo nivel asociados a la eficiencia o a las estructuras físicas de los datos.

Aunque la notación original diseñada por Chen es ampliamente utilizada en los textos académicos y revistas, rara vez es vista en las herramientas CASE. Los diseñadores de bases de datos suelen utilizar esta metodología para cumplir con los requisitos y definir la arquitectura de los sistemas de base de datos, pero no la usan para el diseño de los sistemas Web; y ello es debido a que el modelo ER no define una sintaxis para representar en forma gráfica los diagramas del modelo, como si lo permite el Lenguaje de Modelado Unificado -UML-, el cual se ha convertido en un estándar para el desarrollo de portales Web.

UML es un lenguaje ampliamente aceptado y usado por los analistas y desarrolladores de software, y es, además, un complemento para la representación gráfica de los diagramas ER

(Gornik, 2006), porque facilita la comunicación entre los miembros del equipo, a la vez que permite la integración de los repositorios de datos. De manera que el modelo ER es la mejor selección que se puede hacer para representar un modelo relacional en forma visual. Sin embargo, existentes diferencias que deben ser comprendidas antes de proceder a diseñar con ER y UML. Debido a que UML derivó de diversos enfoques, no es una notación única, sino una serie de anotaciones para los elementos de modelado, particularmente clases, comportamientos y eventos.UML es un lenguaje de notación creado inicialmente para el diseño de software que se ha expandido en el diseño del negocio y base de datos. Incluye elementos y esquemas necesarios que van desde el análisis hasta la implementación y desarrollo de un sistema.

Aunque pareciera existir una separación entre el lenguaje UML y el modelo ER desde el punto de vista de la concepción de los objetos, el lenguaje de modelado UML tiene sus raíces en el modelo ER. Los autores del UML han proclamado que el lenguaje es diferente al modelado de datos y no tiene nada que ver con el diseño de bases de datos; sin embargo, la Object Management Group (OMG, 2008) ha trabajado en producir un conjunto de “metamodelos” para describir el modelado entidad relación, así como el diseño de bases de datos relacionales y el diseño de esquemas XML, de manera de producir Modelos Entidad Relación "conceptuales" con el uso de notación de clases en UML (Hay, 1999). Por otro lado, si se pretende desarrollar plataformas que permitan el uso de diferentes herramientas de análisis, diseño e implementación, las cuales posiblemente están basadas en diversos modelos (por ejemplo, con UML y las diversas variantes de ER) con el uso de la ingeniería de reversa, los diagramas ER pueden ser vistos como un diagrama de clases de de UML, lo cual permite cambiar, mejorar o actualizar las abstracciones de las bases de datos, y además, integrar los nuevos diseños con otros existentes. En tal caso, se requiere un mapeo de los diagramas del modelo ER a UML que lo ideal sería que las transformaciones se lograran en forma automática.

Abstracción

El Modelo Entidad Relación es una herramienta apropiada en la transformación de un sistema de mundo real a un modelo conceptual. Para muchos diseñadores y modeladores de sistemas el mundo es visto en una forma abstracta, por ello su preocupación se basa en describir con precisión el negocio, en lugar de preocuparse acerca de detalles tales como el rendimiento de la base de datos. La Figura 2 muestra el nivel conceptual abstracto en un determinado nivel de dominio; a este nivel, el lenguaje es usado para describir un modelo a diferentes niveles de abstracción. En el nivel lógico se prepara el modelo conceptual para la implementación del sistema, usando para ello el modelo relacional (Entidad Relación). Finalmente, el modelo físico es la representación del modelo desde los niveles más altos de un sistema específico (por ejemplo, con los detalles del almacenamiento de datos).

Figura 2. Modelos de data en diferentes niveles de

abstracción

Modelos

El modelaje de datos bajo el enfoque orientado por el modelo ER permite desarrollar muchas ideas diferentes sobre lo que pudiera constituir un buen modelo de datos, porque se trata de asuntos semánticos y no de cuestiones técnicas. Los modelos de clases UML que apoyan el diseño se parece mucho al modelo ER en el análisis de requisitos. En el modelo ER, el tipo entidad es una descripción o plano que puede producir cualquier cantidad de artefactos que se diferencian entre sí, únicamente por su identidad y estado. El elemento correspondiente en UML es la “clase”. Aunque el modelo ER utiliza las clases de una manera similar a los de UML, existen diferencias de alcance. En primer lugar, una "entidad" en el modelo ER no se refiere a las operaciones, los métodos, o el comportamiento, sino que sólo se refiere a la estructura de los datos. En segundo lugar, una entidad clase en el modelo ER, no es cualquier entidad discreta con un límite bien definido, sino que se limita a lo que Richard Barker llama las cosas u objetos, "de importancia real o imaginaria cuya información debe ser conocida o mantenida" (Barker 1989).

El diagrama de clases es central para el UML debido a que presenta las abstracciones en un sistema y cómo ellos se

relacionan. Esto es así porque la clase, por definición, tiene la capacidad de ocultar el contenido, mientras que la entidad tiene interfaces de acceso. Una de las ventajas de UML es que puede ser usado en todos los niveles de abstracción, desde el nivel conceptual (por ejemplo, describiendo los procesos del negocio) o a nivel de implementación (por ejemplo, definiendo las clases escritas en un lenguaje específico de programación). Y ello es debido a que el modelo de clases de UML es conceptualmente diferente del modelo ER, porque este último restringe a las entidades de clase sólo a aquellas cosas importantes para el negocio, en cambio para UML casi cualquier cosas puede ser un objeto que se recoge en las clases. Sin embargo, no existe posibilidad de representar características particulares de algunos tipos de datos (por ejemplo, los datos asociados con las propiedades de temporalidad y espacialidad que requieren algunos fenómenos geográficos propios del los sistemas geo-referenciados).

Notación básicaUML ayuda a abordar áreas que corresponden al inicio temprano del desarrollo del ciclo de vida del modelo conceptual, de manera que el modelo ER puede ser “mapeado” en un modelo UML, a través de un conjunto de reglas de transformación. Ello es debido a que tanto la notación del Modelo Entidad Relación como el Lenguaje Unificado de Modelado pueden describir entidades clases y relaciones.

Antes de comenzar con UML, se puede crear el diagrama de ER, simplemente utilizando las clases (las clases tienen la forma de "entidad" del modelo ER, de manera que se comportan como cualquier entidad), los atributos y sus asociaciones (es decir, relaciones) a otras entidades.

Para realizar un mapeo desde el modelo ER a UML no existe un lenguaje para definir el modelado en el cual se definan los metamodelos de UML, como si existe en las transformaciones entre UML y MDA (Arquitectura Dirigida por Modelos). Sin embargo, el metamodelado en ER es importante porque define un modelado abierto al entendimiento humano, y sirve de herramienta para la transformación en un lenguaje adecuado para el desarrollo de modelos.

El objetivo final de usar UML como notación de modelado de datos es proporcionar mecanismos que orienten sobre cómo producir un modelo entidad relación conceptual, usando la notación del Diagrama de Clase de UML. Por lo tanto, el lenguaje UML funciona de una manera semi-formal como un metamodelo. Para alcanzar este modelaje con UML es importante tener en cuenta tres cosas:

Solamente son tratadas las clases entidad que pertenecen al contexto del negocio analizado.

Solamente un subconjunto de la notación utilizada en UML puede ser usado para representar la semántica de un negocio.

El significado de los símbolos es diferente del que tienen los símbolos en el mundo orientado a objetos.

Para Fuster, Llorens, Fuentes, Morato y Martínez (2011) cada vez que hay una voluntad de expresar una propiedad del modelo, para transmitir alguna información al respecto, hay que reconocer una intención semántica, no sólo una estética. En ello, los diagramas de ER expresados con notación UML son particularmente apropiados de usar, porque además de ser estéticamente pulcros, transmiten una semántica precisa del sistema a implementar.

La Figura 3 es un sencillo ejemplo de un diagrama ER que usa la notación UML, en un sistema de administración de un portal de gobierno electrónico para el registro de un Consejo Comunal.

Figura 3. Diagrama Entidad Relación usando notación

UML

La Figura 3A muestra un ejemplo de un fragmento de un modelo en notación ER. Una instancia de un “REGISTRO Consejo Comunal” describe los valores de "Número de registro" y "Fecha de registro", mientras que “Consejo Comunal miembros” es descrito por los valores del "Número de consejo", "Cantidad de miembros", "Municipio", y "Parroquia". La relación “Consejo comunal ubicado” es de uno a cero o muchos.

Figura 3A: Notación Modelo ER

Es importante destacar que sintácticamente los términos usados para representar los nombres de las clases de entidad y los nombres de las funciones son abiertos al entendimiento humano. De manera que las convenciones tipográficas (mayúsculas y cursivas) son innecesarias. El ejemplo de la Figura 3A, muestra las etiquetas de los atributos y entidades que están correctamente construidas, de manera que se permiten etiquetas abiertas (con espacios en blanco). Si se tratara de la notación del lenguaje UML debería ser más estricto porque se trata de los aspectos tecnológicos y no del proceso de negocios, tal como lo expresa la Figura 3B relacionada con el mismo modelo en notación UML.

Figura 3B: Notación UML

Semánticamente las dos formas de las Figuras 3A y 3B son equivalentes, sin embargo, podríamos señalar que el esquema de notación planteado por la Figura 3A corresponde al modelo lógico, mientras que la Figura 3B al modelo físico.

Clase, atributos, relaciones y cardinalidad

De acuerdo a la semántica de UML, una clase es el descriptor para un conjunto de objetos con similar estructuras, conductas y relaciones. Una clase corresponde a la implementación del tipo, la cual puede tener atributos que definen su estructura y operaciones y define también las conductas de las instancias de la clase.

Un objeto es una entidad en el modelo Entidad Relación, por lo tanto, una clase es “mapeada” en un tipo entidad en el modelo ER. Atributos de la clase son mapeados a atributos de las entidades tipos resultantes. En UML se asume que cada objeto (instancia de una clase) es únicamente identificado por su objeto identificador (OID).

En el modelo ER una entidad se distingue de otra entidad por el valor del atributo clave.

Clase - Entidad

Una clase de una entidad en el modelo ER es el nombre de una "cosa” u objeto de importancia para una organización o negocio, ya sea real o imaginaria, cuya información se necesita conocer o mantener (Barker, 1989). Puede ser una cosa concreta, como una persona o la ubicación geográfica; o puede ser una abstracción como “Consejo Comunal miembros” o” Rol en el ConsejoComunal”. En UML, un subconjunto del concepto de "clase" puede utilizarse siempre y cuando se entienda dentro del modelo ER. El nombre de la clase entidad es una particularidad y refiere a una instancia de esa clase.

Atributos

Al igual que en UML, un atributo en el modelo entidad relación es una característica de una clase de entidad que "sirve para calificar, identificar, clasificar, cuantificar o expresar el estado de una entidad" (Barker, 1989, p. 5-6). Pero además, UML tiene la capacidad de mostrar un gran número de cosas acerca de un atributo: su tipo de datos, su "visibilidad" por ejemplo, si se trata de "sólo lectura" o no. En cambio en el modelo ER sólose muestra el nombre del atributo, si es opcional o no, a lo sumo, opcionalmente se puede indicar si el atributo es derivado.

Relaciones y cardinalidad

Una relación es una colección semántica entre las clases. Hay diversos tipos de relaciones en UML: asociación bidireccional; asociación unidireccional; dependencia; asociación de agregación; herencia y la plantilla de creación de instancias. Una relación entre dos clases de entidad se compone de dos aseveraciones acerca de ellas. Cada afirmación es el papel de una clase entidad con respecto a las demás. Esto puede ser descrito en UML mediante una línea de "asociación". Una asociación UML es equivalente a una relación con la entidad, a diferencia del modelo ER donde una relación es más limitada en cuanto a lo que puede representar una asociación orientada a objetos como en UML. En concreto, como se describe a continuación, cada relación es un par de afirmaciones sobre la naturaleza del negocio. No es simplemente el reconocimiento de que dos cosas están de alguna manera relacionadas entre sí.

En UML, la cardinalidad es representada mediante los caracteres: ".. 1" (lo que significa que una instancia de la clase primera entidad se puede asociar a no más de una instancia de la segunda clase); o con los caracteres "..*" (que significa que la primera entidad puede estar asociada con un número ilimitado de instancias de la segunda clase). También, una relación puede ser "0 .."

(que significa que la relación es opcional) o "1 .." (significa que se requiere). UML, al contrario de lo expresado en el modelo entidad/relación es compatible con una variedad de valores de cardinalidad máxima. Por ejemplo, la expresión podría ser "1,5,> 9 ", es decir, el valor debe ser exactamente 1 o 5, o superior a 9.

A diferencia del uso convencional dado en UML, cada relación se compone de dos frases aunque con estructura rigurosa. Cada final de la relación se denomina en UML el "rol". Así, la relación representada en la Figura 3B muestra la cardinalidad y opcionalidad en términos gráficos (Ver Figura 3C).

Figura 3C: Relación en notación UML

La interpretación del rol si se lee de derecha a izquierda es:

Cada REGISTROConsejoComunal puede estar compuesto de uno o más de Consejo_Comunal_miembros

Si se lee de izquierda a derecha:

Cada Consejo_Comunal_miembros debe ser parte de exactamente un REGISTROConsejoComunal

Estas son frases no técnicas y deberían ser plena y fácilmente, por lo tanto, cualquiera debería entender la naturaleza de la relación.

Adicionalmente, UML proporciona una serie de capacidades útiles. Por ejemplo, se puede representar la asociación “muchos a muchos” directamente en los modelos de datos, junto con la correspondiente asociación de entidades (conocidas como “intersección”) (ver Figura 4), La asociación entidad pertenece a la relación y no a cualquiera otra de las dos entidades participantes. Esto permite tener una visualización real de los elementos del modelo, incluidos los atributos adicionales definidos dentro de la asociación entidad.

Este tipo de relaciones explícitamente representadas permite a los interesados entender estas entidades y resolver las estructuras de una base de datos que responda a los requerimientos de la organización o del negocio. Se pueden utilizar los casos de uso de UML para crear un modelo del modelo existente, y de las funciones deseadas.

Figura 4: Relación "Muchos a Muchos" usando la

notación UML

La simplicidad de los diagramas de casos de uso permite a la organización, al equipo de desarrollo de la base de datos entender fácilmente estos modelos. El modelado de casos de uso es una forma sencilla de a) entender el negocio actual, b) obtener los requisitos deseados para el nuevo sistema que se va a crear, y c) establecer quiénes se estarán comunicando con el sistema y de qué forma.

Super tipos y sub tipos

Cuando las instancias de una clase entidad se puede dividir en dos o más clases, cada una de las clases subalternas "heredan" los atributos y las relaciones de la clase entidad original, estas clases subordinadas se llaman subtipos (Ver Figura 5A).

Figura 5A Subtipos de una clase

Persona y Organización son subtipos de Consejo Comunal. Cada instancia del Consejo Comunal es una instancia de Persona o de Organización. Por otro lado, Organización es un supertipo de Líder comunal y de Organizador Político.

Es posible que una clase entidad sea designada como un subtipo de otra, gráficamente la caja está dentro de otra caja. La Figura 5B muestra la forma (a partir de la notación en el modelo ER) que en UML se representan los subtipos: fuera del área super-tipo, que se asocian a través de flechas especializadas.

Figura 5B Subtipos de una clase en UML

Hay que tomar en cuenta que si se tienen muchos subtipos, el diagrama se puede llenar y restar importancia a otras estructuras del sistema. Si los subtipos se anidan

con profundidad, se hace difícil determinar cuál instancia es sub-tipo de otra. Los atributos y las relaciones en los niveles superiores no son, los mismos atributos y relaciones del menor nivel de sub-tipos.

Las herramientas UML permiten, a partir del modelo ER, mostrar cajas de subtipos dentro de los super tipos. Para ello, primero se debe crear las líneas de las estructuras generales y luego mover las cajas sub tipos adentro de las cajas super tipos y luego se borran las líneas de los objetos gráficos que representan las relaciones de los subtipos (Ver Figura 5C).

Figure 5C Sub-Tipos en la conversión ER - UML

Es de suponer que el modelador del sistema debe estar pendiente de: a) Integridad. Cada instancia de la entidad super-tipo debe ser una instancia de uno de los sub-tipos. Esto es equivalente en UML a llamar a la super-tipo "abstracto". Es decir, en UML se puede imponer esta restricción o no. En el modelado de datos, la restricción se aplica siempre, pero puede refinarse mediante la adición de un sub-tipo; b) Exclusividad. No hay instancia de la super-tipo que pueda ser una instancia de más de uno de los sub-tipos, c) No hay herencia múltiple. Cada subtipo puede tener sólo un super-tipo.

ConclusionesEl Modelo Entidad Relación puede servir de fundamento natural que sustente el entendimiento de modelos, y como herramienta fundamental para capturar la información requerida. Como se ha sugerido en las secciones previas, el objetivo de este trabajo fue la de describir cómo un esquema basado en el modelo Entidad Relación puede mejorarse si se diseña bajo el lenguaje UML. Uno podría automáticamente “mapear” un modelo lógico de datos ER a su correspondiente modelo de clase

en UML, a través de un sistema que permita rediseñar en un primer paso a través del enfoque de ingeniería reversa de datos, en un diseño de una base de datos existente en un modelo de datos físico, transfiriendo el diagrama ER lógico a través del mapeo a un modelo de clase de UML.

Tradicionalmente, la conversión de la data se deja para que la realicen los programadores. Los modelos lógicos más habituales (como es el modelo relacional) y los lenguajes de bases de datos (como lo es el SQL) no proporcionan una representación explícita de las relaciones; por lo tanto, se deben establecer estrategias de traducción con el fin de transformar los tipos de estructuras datos en unas estructuras que sean adecuadas al contexto de desarrollo de los sistemas de información.

El objetivo del modelado entidad-relación (ER) es crear una representación válida de las entidades, sus atributos y sus relaciones de manera que satisfagan las necesidades del negocio o la organización. Si bien la mayoría de las notaciones de modelado disponibles pueden servir para este propósito, el lenguaje de modelado unificado (UML) permite flexibilidad para lograr este objetivo, especialmente cuando se trata de la parte de la organización o negocio.

Para convertir un esquema relacional a otro esquema de datos, primero se debería mapear el esquema relacional en un modelo ER, para luego convertirlo en un diagrama basado en el lenguaje UML, a fin de obtener beneficios de su uso en la creación de los modelos lógicos de la ER. Es decir, se pretende partir de un modelo conceptual que luego permita trasladar modelo de datos en un modelo en UML cuyo destino final podría ser cargado en una base de datos.

El desarrollo de un sistema de gobierno electrónico considerara que el modelo se supedite a las instancias legales; por lo tanto, las entidades y relaciones que conforman el sistema deben estar diseñadas para cumplir con los requisitos de la administración pública. De manera que la calidad de un portal de gobierno electrónico depende fundamentalmente de su diseño y de la notación que se haga de los datos en el modelo. Por eso, nuestra propuesta de conversión entre ER y UML se basó en un enfoque de “metamodelado”. En este trabajo se detalló cómo los diferentes componentes de un modelo y, en particular cómo el componente de datos, en relación con su manipulación y con sus estructuras ha de llevarse a cabo para desarrollar las relaciones en el contexto de los servicios web.

Independientemente de la aparición de los nuevos paradigmas informáticos, por múltiples razones, la creación de sistemas en portales web requiere el concurso y la experiencia de viejos estilos y disciplinas de desarrollo de sistemas que son independientes de los software de

aplicación, que están disponibles en el mercado. La metodología de desarrollo de modelos ha sido probada para el desarrollo de sistemas de información que permita la creación de sistemas acordes con el desarrollo de los portales de gobierno electrónico

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] Según la variabilidad de los datos almacenados

[editar] Bases de datos estáticas

Son bases de datos de sólo lectura, utilizadas primordialmente para almacenar datos históricos que posteriormente se pueden utilizar para estudiar el comportamiento de un conjunto de datos a través del tiempo, realizar proyecciones, tomar decisiones y realizar análisis de datos para inteligencia empresarial.

[editar] Bases de datos dinámicas

Éstas son bases de datos donde la información almacenada se modifica con el tiempo, permitiendo operaciones como actualización, borrado y adición de datos, además de las operaciones fundamentales de consulta. Un ejemplo de esto puede ser la base de datos utilizada en un sistema de información de un supermercado, una farmacia, un videoclub o una empresa.

[editar] Según el contenido

[editar] Bases de datos bibliográficas

Sólo contienen un subrogante (representante) de la fuente primaria, que permite localizarla. Un registro típico de una base de datos bibliográfica contiene información sobre el autor, fecha de publicación, editorial, título, edición, de una determinada publicación, etc. Puede contener un resumen o extracto de la publicación original, pero nunca el texto completo, porque si no, estaríamos en presencia de una base de datos a texto completo (o de fuentes primarias —ver más abajo). Como su nombre lo indica, el contenido son cifras o números. Por ejemplo, una colección de resultados de análisis 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 colección de revistas científicas.

http://es.wikipedia.org/w/index.php?title=Base_de_datos&action=edit&section=7




http://es.wikipedia.org/wiki/Inteligencia_empresarial

http://es.wikipedia.org/wiki/Decisiones

http://es.wikipedia.org/w/index.php?title=Proyecciones&action=edit&redlink=1



[editar] Directorios

Un ejemplo son las guías telefónicas en formato electrónico.

[editar] Bases de datos o "bibliotecas" de información química o biológica

Son bases de datos que almacenan diferentes tipos de información proveniente de la química, las ciencias de la vida o médicas. Se pueden considerar en varios subtipos:

Las que almacenan secuencias de nucleótidos o proteínas. Las bases de datos de rutas metabólicas. Bases de datos de estructura, comprende los registros de datos experimentales sobre

estructuras 3D de biomoléculas- Bases de datos clínicas. Bases de datos bibliográficas (biológicas, químicas, médicas y de otros campos): PubChem,

Medline, EBSCOhost.

[editar] Modelos de bases de datos

Además de la clasificación por la función de las bases de datos, éstas también se pueden clasificar de acuerdo a su modelo de administración de datos.

Un modelo de datos es básicamente una "descripción" de algo conocido como contenedor de datos (algo en donde se guarda la información), así como de los métodos para almacenar y recuperar información de esos contenedores. Los modelos de datos no son cosas físicas: son abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemáticos.

Algunos modelos con frecuencia utilizados en las bases de datos:

[editar] Bases de datos jerárquicas

Artículo principal: Base de datos jerárquica.

En este modelo los datos se organizan en una forma similar a un árbol (visto al revés), en donde un nodo padre de información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los conoce como hojas.

Las bases de datos jerárquicas son especialmente útiles en el caso de aplicaciones que manejan un gran volumen de información y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento.

Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos.

[editar] Base de datos de red

Artículo principal: Base de datos de red.

http://es.wikipedia.org/wiki/Base_de_datos_de_red


http://es.wikipedia.org/wiki/Base_de_datos_jer%C3%A1rquica


http://es.wikipedia.org/wiki/Algoritmo


http://es.wikipedia.org/wiki/EBSCOhost

http://es.wikipedia.org/wiki/PubChem

http://es.wikipedia.org/wiki/Medicina

http://es.wikipedia.org/wiki/Ciencias_de_la_vida

http://es.wikipedia.org/wiki/Qu%C3%ADmica

http://es.wikipedia.org/wiki/Gu%C3%ADa_telef%C3%B3nica


Éste es un modelo ligeramente distinto del jerárquico; su diferencia fundamental es la modificación del concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico).

Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de redundancia de datos; pero, aun así, la dificultad que significa administrar la información en una base de datos de red ha significado que sea un modelo utilizado en su mayoría por programadores más que por usuarios finales.

[editar] Bases de datos transaccionales

Son bases de datos cuyo único fin es el envío y recepción de datos a grandes velocidades, estas bases son muy poco comunes y están dirigidas por lo general al entorno de análisis de calidad, datos de producción e industrial, es importante entender que su fin único es recolectar y recuperar los datos a la mayor velocidad posible, por lo tanto la redundancia y duplicación de información no es un problema como con las demás bases de datos, por lo general para poderlas aprovechar al máximo permiten algún tipo de conectividad a bases de datos relacionales.

Un ejemplo habitual de transacción es el traspaso de una cantidad de dinero entre cuentas bancarias. Normalmente se realiza mediante dos operaciones distintas, una en la que se decrementa el saldo de la cuenta origen y otra en la que incrementamos el saldo de la cuenta destino. Para garantizar la atomicidad del sistema (es decir, para que no aparezca o desaparezca dinero), las dos operaciones deben ser atómicas, es decir, el sistema debe garantizar que, bajo cualquier circunstancia (incluso una caída del sistema), el resultado final es que, o bien se han realizado las dos operaciones, o bien no se ha realizado ninguna.

[editar] Bases de datos relacionales

Artículo principal: Modelo relacional.

Artículo principal: Base de datos relacional.

Éste es el modelo utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postulados sus fundamentos 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. Su idea fundamental es el uso de "relaciones". Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados "tuplas". Pese a que ésta es la teoría de las bases de datos relacionales creadas por Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar. Esto es pensando en cada relación como si fuese una tabla que está compuesta por registros (las filas de una tabla), que representarían las tuplas, y campos (las columnas de una tabla).

En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos. La información

http://es.wikipedia.org/wiki/Registro_(base_de_datos)

http://es.wikipedia.org/wiki/Tupla

http://es.wikipedia.org/wiki/San_Jos%C3%A9_(California)

http://es.wikipedia.org/wiki/San_Jos%C3%A9_(California)

http://es.wikipedia.org/wiki/IBM

http://es.wikipedia.org/wiki/Edgar_Frank_Codd

http://es.wikipedia.org/wiki/1970

http://es.wikipedia.org/wiki/Base_de_datos_relacional

http://es.wikipedia.org/wiki/Modelo_relacional



puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información.

El lenguaje más habitual para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales.

Durante su diseño, una base de datos relacional pasa por un proceso al que se le conoce como normalización de una base de datos.

Durante los años 80 la aparición de dBASE produjo una revolución en los lenguajes de programación y sistemas de administración de datos. Aunque nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su gestión.

[editar] Bases de datos multidimensionales

Artículo principal: Base de datos multidimensional.

Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como creación de Cubos OLAP. Básicamente no se diferencian demasiado de las bases de datos relacionales (una tabla en una base de datos relacional podría serlo también en una base de datos multidimensional), la diferencia está más bien a nivel conceptual; en las bases de datos multidimensionales los campos o atributos de una tabla pueden ser de dos tipos, o bien representan dimensiones de la tabla, o bien representan métricas que se desean estudiar.

[editar] Bases de datos orientadas a objetos

Artículo principal: Base de datos orientada a objetos.

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).

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.

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. Los programas de aplicación de los usuarios pueden operar sobre

http://es.wikipedia.org/wiki/Polimorfismo_(inform%C3%A1tica)

http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

http://es.wikipedia.org/wiki/Programaci%C3%B3n_orientada_a_objetos

http://es.wikipedia.org/wiki/Base_de_datos_orientada_a_objetos


http://es.wikipedia.org/wiki/Cubo_OLAP

http://es.wikipedia.org/wiki/Base_de_datos_multidimensional


http://es.wikipedia.org/wiki/DBase

http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_una_base_de_datos

http://es.wikipedia.org/wiki/SQL

los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones.

SQL:2003, es el estándar de SQL92 ampliado, soporta los conceptos orientados a objetos y mantiene la compatibilidad con SQL92.

[editar] Bases de datos documentales

Permiten la indexación a texto completo, y en líneas generales realizar búsquedas más potentes. Tesaurus es un sistema de índices optimizado para este tipo de bases de datos.

[editar] Bases de datos deductivas

Un sistema de base de datos deductiva, es un sistema de base de datos pero con la diferencia de que permite hacer deducciones a través de inferencias. Se basa principalmente en reglas y hechos que son almacenados en la base de datos. Las bases de datos deductivas son también llamadas bases de datos lógicas, a raíz de que se basa en lógica matemática. Este tipo de base de datos surge debido a las limitaciones de la Base de Datos Relacional de responder a consultas recursivas y de deducir relaciones indirectas de los datos almacenados en la base de datos.

[editar] Lenguaje

Utiliza un subconjunto del lenguaje Prolog llamado Datalog el cual es declarativo y permite al ordenador hacer deducciones para contestar a consultas basándose en los hechos y reglas almacenados.

[editar] Ventajas

Uso de reglas lógicas para expresar las consultas. Permite responder consultas recursivas. Cuenta con negaciones estratificadas Capacidad de obtener nueva información a través de la ya almacenada en la base de datos

mediante inferencia. Uso de algoritmos de optimización de consultas. Soporta objetos y conjuntos complejos.

[editar] Desventajas

Crear procedimientos eficaces de deducción para evitar caer en bucles infinitos. Encontrar criterios que decidan la utilización de una ley como regla de deducción. Replantear las convenciones habituales de la base de datos.

[editar] Fases

Fase de Interrogación: se encarga de buscar en la base de datos informaciones deducibles implícitas. Las reglas de esta fase se denominan reglas de derivación.







http://es.wikipedia.org/wiki/SQL:2003

Fase de Modificación: se encarga de añadir a la base de datos nuevas informaciones deducibles. Las reglas de esta fase se denominan reglas de generación.

[editar] Interpretación

Encontramos dos teorías de interpretación de las bases de datos deductivas:

Teoría de Demostración: consideramos las reglas y los hechos como axiomas.

Los hechos son axiomas base que se consideran como verdaderos y no contienen variables. Las reglas son axiomas deductivos ya que se utilizan para deducir nuevos hechos.

Teoría de Modelos: una interpretación es llamada modelo cuando para un conjunto específico de reglas, éstas se cumplen siempre para esa interpretación. Consiste en asignar a un predicado todas las combinaciones de valores y argumentos de un dominio de valores constantes dado. A continuación se debe verificar si ese predicado es verdadero o falso.

[editar] Mecanismos

Existen dos mecanismos de inferencia:

Ascendente: donde se parte de los hechos y se obtiene nuevos aplicando reglas de inferencia.

Descendente: donde se parte del predicado (objetivo de la consulta realizada) e intenta encontrar similitudes entre las variables que nos lleven a hechos correctos almacenados en la base de datos.

[editar] Gestión de bases de datos distribuida (SGBD)

La base de datos y el software SGBD pueden estar distribuidos en múltiples sitios conectados por una red. Hay de dos tipos:

1. Distribuidos homogéneos: utilizan el mismo SGBD en múltiples sitios.

2. Distribuidos heterogéneos: Da lugar a los SGBD federados o sistemas multibase de datos en los que los SGBD participantes tienen cierto grado de autonomía local y tienen acceso a varias bases de datos autónomas preexistentes almacenados en los SGBD, muchos de estos emplean una arquitectura cliente-servidor.

Estas surgen debido a la existencia física de organismos descentralizados. Esto les da la capacidad de unir las bases de datos de cada localidad y acceder así a distintas universidades, sucursales de tiendas, etcétera.




Gestores de bases de datos.

-4.1. Que son sistemas gestores de bases de datos.

Son un tipo de software muy específico, dedicado a servir de interfaz entre las bases de datos, el usuario y las aplicaciones

que la utilización.

-4.2. .. Que objetivos debe cumplir.

Abstracción de información: Los SGBD ahorran a los usuarios detalles acerca del almacenamiento físico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario. Así, se definen varios niveles de abstracción.

Independencia: La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.

Consistencia: En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultánea. Por otra parte, la base de datos representa una realidad determinada que tiene determinadas condiciones, por ejemplo que los menores de edad no pueden tener licencia de conducir. El sistema no debería aceptar datos de un conductor menor de edad. En los SGBD existen herramientas que facilitan la programación de este tipo de condiciones.

Seguridad: La información almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta información se encuentra segura de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categorías de permisos.

Manejo de transacciones: Una transacción es un programa que se ejecuta como una sola operación. Esto quiere decir que luego de una ejecución en la que se produce una falla es el mismo que se obtendría si el programa no se hubiera ejecutado. Los SGBD proveen mecanismos para programar las modificaciones de los datos de una forma mucho más simple que si no se dispusiera de ellos.

Tiempo de respuesta: Lógicamente, es deseable minimizar el tiempo que el SGBD demora en proporcionar la información solicitada y en almacenar los cambios realizados

.-4.3. Cuales son sus ventajas y desventajas.

Ventajas:

Provee facilidades para la manipulación de grandes volúmenes de datos.

Simplifica la programación de equipos de consistencia. Manejando las políticas de respaldo adecuadas,

garantizan que los cambios de la base serán siempre consistentes sin importar si hay errores correctamente.

Organizar los datos con un impacto mínimo en el código

de los programas. Disminuyen drásticamente los tiempos de desarrollo y

aumentan la calidad del sistema desarrollado si son bien explotados por los desarrollos.

Usualmente, proveen interfaces y lenguajes de consulto

que simplifican la recuperación de los datos.

Desventajas:

Tamaño: la complejidad y la gran cantidad de funciones que tienen, hacen que sea un software de gran tamaño, que requiere de gran cantidad de memoria para poder correr.

Costo de Hadware adicional: los requisitos de hadware para correr un SGBD por lo general son relativamente altos, y estos equipos pueden llegar a costar grandes cantidades de dinero.

Si se tiene muy pocos datos que son usados por un único usuario por vez y no hay que realizar consultas sobre datos, entonces es posible que sea mejor usar una hoja de cálculo.

Complejidad: el software muy complejo y las personas que vayan a usarlo deben tener conocimiento de las funcionalidades del mismo para poder aprovecharlo al máximo.

-4.4. SGBD disponibles. Cuales son sus características y cual es su uso preferencial.

-MYSQL:

Amplio subconjunto del lenguaje SQL-algunas extensiones son incluidas igualmente.

Disponibilidad de gran cantidad de plataformas y

sistemas. Posibilidad de selección de mecanismos de

almacenamiento que ofrecen diferente velocidad de operación, soporte físico, capacidad, distribución geográfica, transacciones.

Transacciones y claves foráneas.

Replicación. Conectividad segura.

- - Uso preferencial:

Para aplicaciones web, como dupral o phpbb, en plataformas, y por herramientas de seguimiento de errores como bugzilla. Su popularidad como aplicaciones web esta muy ligada a php, que a menudo aparece en combinaciones con MYSQL.

--POSTGRESQL:

Alta concurrencia: permite que mientras una persona este en la tabla y otra persona pueda entrar, sin bloqueos.

Amplia variedad de tipos nativos, provee nativamente

soportes para:

-números de precisión orbitaria.

-texto de largo ilimitado.

-figuras geométricas.

-uso preferencial:

Lo utilizan en empresas para comercializar.

-FIREBIRDSQL:

Es multiplataforma y se pueden ejecutar en sistemas operativos.

Soporte de user- defined fundctios. Es mediante escalables. Buena seguridad basada en usuarios. Capacidad de almacenar elementos. BLOB

-uso preferencial:

Para administrar bases de datos relacional.

-4.5. Que es Microsoft Access. Que se puede hacer con el.

Microsoft Access: es un programa que permite el ingreso y almacenamiento de datos mediante la programación y creación de formularios, así como otras actividades como consultas e informes impresos.

Que se puede hacer con el: crear ficheros con bases de datos.

-4.6. Con el enfoque u orientación del Access defina los siguientes elementos.

Tablas: son el componente básico o elemental de las bases de datos, o lo que es lo mismo, una base de datos esta principalmente compuesta por varias tablas relacionadas. Las tablas contienen datos sobre algo o alguien, proveedores, clientes, libros en una biblioteca, compras, ventas, etc.

Entidades: una entidad es la que guarda información relacionada con el producto o lo que deseamos guardar.

Relaciones: es el coincidir de los datos de las columnas de clave, normalmente las columnas con el

mismo nombre ambas tablas.

Campos: es cada uno de los tipos de datos que se van a usar. Se hace referencia a los campos por su nombre.

Registros: un registro es la información particular.

Publicado por marce en 20:12 Sin comentarios:

Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con Facebook

Bases de datos.

http://www.blogger.com/share-post.g?blogID=1455156698749457978&postID=5197443472214851354&target=facebook


http://www.blogger.com/share-post.g?blogID=1455156698749457978&postID=5197443472214851354&target=twitter

http://www.blogger.com/share-post.g?blogID=1455156698749457978&postID=5197443472214851354&target=blog

http://www.blogger.com/share-post.g?blogID=1455156698749457978&postID=5197443472214851354&target=email

http://linaospinaarcosbasededatos.blogspot.com/2012/04/gestores-debases-de-datos.html#comment-form

http://linaospinaarcosbasededatos.blogspot.com/2012/04/gestores-debases-de-datos.html

http://www.blogger.com/profile/01567143621887604709

http://www.blogger.com/post-edit.g?blogID=1455156698749457978&postID=5197443472214851354&from=pencil

3.1-. Cuales son sus características.

.Permite que sólo se puedan ver, los registros de la base de datos, cuando el usuario haya introducido un determinado número de registros en ella.

.Permite configurar los derechos de edición. Puede agregar entradas profesores y alumnos, si lo permite en la base de datos. Esto no restringe la visualización de sus entradas para todos.

Se puede limitar el número máximo de entradas de cada participante.

Podemos permitir añadir comentarios a las entradas de la base de datos

Podemos habilitar la revisión del profesor antes de que las entradas sean publicas.

-.3.2. Relacione sus ventajas.

.se puede almacenar grandes cantidades de datos o información.

compartir datos.

flexibilidad y rapidez al obtener datos.

seguridad.

independencia de datos

redundancia controlada.

-3.3. Especifique sus desventajas.

.tamaño: el sistema de manejo de base de datos (DBMS) requiere de mucho espacio en disco duro y también requiere de mucha memoria principal (RAM).

.complejidad: debido a la cantidad de operaciones y a las capacidades del DBMS, se convierte en un producto complejo de entender.

.costo: los productores de bases de datos (ORACLE, DB2, ETC) son productores caros.

requerimiento adicional del equipo: el adquirir un producto de base de datos, requiere a su vez adquirir equipo adicional para poder correr ese producto como por ejemplo, servidores, memorias, discos duros, etc.

.complejo al recuperar los datos: en caso de accidente que corrompa la base de datos, el proceso de recuperación y de volver a la base de datos su estado al problema, es mucho mas complejo que ejecutar que en sistemas tradicionales.

-3.4. Cual es el uso actual de las bases de datos.

 Una base de datos es la manera actual de recopilar y guardar archivos de cualquier índole.

-3.5. Que no es una base de datos.

Software. Tecnología.



-3.6. Porque no es indispensable tanto software como la tecnología para hablar de base de datos.

Software: por que es una herramienta principal del enfoque de la administración de base de datos, dado que controla la creación, el mantenimiento y el uso de la base de datos de una organización y de sus usuarios finales.


Funciones.


1. Crear nuevas bases de datos y aplicaciones para ella.

2. Mantener la calidad de la información en las bases de datos de una organización.

3. Utilizar las bases de datos de una organización para proporcionar la información necesaria para sus usuarios finales.

Tecnología: las cosas van avanzando, las personas necesitan ir de la mano con estos avances y buscar lo mejor y lo mas adecuado para su comodidad , por eso es importante e indispensable, la tecnología para una base de datos que son tan utilizados en empresas.

-3.7. Diferencias entre una base de datos dinámica y una estática. Ejemplos de cada una.

 base de datos dinámica:

-la información almacenada con el tiempo se modifica.

-permite operaciones como actualización, borrado y adición de datos.

 base de datos estáticas:

-bases de datos de solo lectura, almacenan datos históricos.

-se utilizan para estudios, compartimientos de un conjunto de datos a

través del tiempo, realizar proyecciones, tomar decisiones y realizar análisis de datos para inteligencia empresarial.

 Ejemplos:

-base de datos dinámica: base de datos utilizada en un sistema de información, de un supermercado, una farmacia, un videoclub, o una empresa.

-base de datos estáticas: en una empresa, sobre el personal de la empresa.

-3.8. Características que presenta una base de datos relacional:

 Una base de datos relacional se compone de varias tablas o relaciones.

 No puede existir dos tablas con el mismo nombre ni registro.

 Cada tabla a su vez en conjunto de registros (filas y columnas).

 Las relación entre una tabla padre y un hijo de lleva acabo por medio de las claves primarias y ajenas (o foráneas).

 Las claves primarias son la clave principal de un registro dentro de una tabla y estas deben cumplir con las la integridad de datos.

 Las claves ajenas se ubican en la tabla hija, contienen el mismo valor que la clave primaria del registro padre; por medio de estas se hacen las relaciones.



Historia de la base de datos.

2.1-.Con que objetivo se crearon las bases de datos.

Para almacenar grandes cantidades de información o datos.

2.2-. Como se manejaban inicialmente las bases de datos.






http://linaospinaarcosbasededatos.blogspot.com/2012/04/bases-dedatos.html#comment-form

http://linaospinaarcosbasededatos.blogspot.com/2012/04/bases-dedatos.html



Las primeras bases de datos manejaban ficheros que almacenados con tarjetas o soportes magnéticos. Cuando evolucionan siguen las cintas y los discos, son dotados de mucha más potencia y facilidad de manipulación.

2.3-. Cuando se vuelven útiles las bases de datos.

Cuando se da la nueva generación se bases de datos que eran las cintas y discos.


http://linaospinaarcosbasededatos.blogspot.com/2012/04/historia-dela-base-de-datos.html#comment-form

http://linaospinaarcosbasededatos.blogspot.com/2012/04/historia-dela-base-de-datos.html




miércoles, 11 de abril de 2012

Sistemas de información.

1.1-.Que es un sistema de información.

Es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objeto.

1.2 -.que elementos conforman un sistema de información, cual es su función. Relaciones ejemplos de cada uno.






-. Entrada: es el proceso mediante el cual el sistema de información toma los datos que se requiere para procesar la información, las entradas pueden ser manuales o automáticas. Ejemplo: mouse, teclado, scanner.

Ejemplo: los proveedores de la empresa Coca-Cola toma sus respectivos datos de los pedidos de las tiendas y supermercados

-. Almacenamiento: es una de las actividades o capacidades más importantes que tiene una computadora ya que a través de esta propiedad el sistema puede recordar la información guardada en la sección o proceso anterior, esta información denominada archivos.

Ejemplo: el proveedor guarda sus respectivos datos de los pedidos requeridos.

-. Procesamiento: es la capacidad del sistema de información para efectuar cálculos de acuerdo con la secuencia de operaciones prestablecidas, estos cálculos pueden efectuarse con datos introducidos recientemente en el sistema o con datos almacenados.

Ejemplo: los datos que el proveedor ingreso siguen una secuencia en la cual esos datos que ingreso se efectúan como

cálculos y pasa la información al repartidor y la empresa lleva sus datos almacenados.

-. Salida de información: es la capacidad de un sistema para sacar la información procesada, las unidades de salida son: monitor, impresora, terminales, disquetes, cintas magnéticas.

Ejemplo: la información que sale es mandada a los repartidores para que hagan su respectiva entrega.

Bases de datos

Una base de datos es un conjunto de datos guardados para despues darle su uso.

En la actualidad la mayoria de las bases de datos se usa de forma electronica o en la informatica, ya que es mucho mas facil y simple. Existen varios tipos de bases de datos, y se clasifican en las siguientes:

1. Bases de datos estaticas: los archivos contenidos en esta base de datos solo son de lectura, y se pueden guardar pero sin usar, o usarlas un tiempo despues, un ejemplo de este seria bibliotecas, periodicos (para almacenar informacion y si se requiere consultarla tiempo despues).

2. Base de datos dinamicas: estas son las mas usadas, ya que como su nombre lo indica con dinamicas, es decir, que se usan constantemente, ya sea modificando o consultando la base de datos, ejemplos de esta seria de tiendas, negocios, en universidades (para los alumnos), etc.

Tambien existen bases de datos de acuerdo a como se administran, aqui les mostrare algunas de las mas usadas.

Bases de datos relacionales: estos son los que se usan para problemas reales o administrar datos de forma dinamica. El programa mas rcomendable para hacer este tipo de base de datos es el SQL, que es el lenguaje mas usado en la actualidad.

http://2.bp.blogspot.com/_db2xaF9w0iw/SwwZB09MiuI/AAAAAAAAABM/8vwBdNDknkA/s1600/bases+de+datos.gif

Base de datos multidimensionales: estas bases de datos se usan para crear aplicaciones muy concretas, como por ejemplo crear cubos OLAP (el almacenamiento fisico se realiza en un vector multidimensional). Se pueden representar por medio de tablas.

Base de datos orientada a objetos: en esta base datos se hacen 3 procedimientos, encapsulacion, que permite ocultar informacion para que no pueda haber conflictos,

http://es.wikipedia.org/wiki/Cubo_OLAP

http://3.bp.blogspot.com/_7vanlXJkv5o/TA029UTO1BI/AAAAAAAAAC4/9zN6fstPYCU/s1600/base83.jpg

http://2.bp.blogspot.com/__rHiC9dO4ww/S_L1TNgFqfI/AAAAAAAAACM/3HY0t3D2h7I/s1600/molap-y-rolap.gif

herencia, que sirve para clasificar en orden las bases de datos, y por ultimo polimorfismo, que es para aplicar operaciones a distintos tipos de objetos.

http://www.rena.edu.ve/cuartaEtapa/Informatica/Imagenes/T9Dib04.gif

Documents

Ejemplos de conexión con bases de datos Access.docx