Bolivarian Republic of Venezuela

Ministry of Popular Power for University Education

Territorial Polytechnic University of the West of Sucre 'Clodosbaldo Russián'
National Training Program in Information Technology
Database modeling

ADVANCED DATABASE DESIGN

Teacher:
Luisana Parejo Authors:
Marcano Jesús ID:18212043
Codino Douglas ID:19239376

Cumaná, October 2013

 Introduction

For the introduction to this chapter, some paragraphs are taken from the text of
Batini, Ceri and Navathe (1994).

Database design is the process by which it is determined

organization of a database, including its structure, content and the
applications that need to be developed. For a long time, the design of databases
data was considered a task for experts: more of an art than a science.
However, there has been significant progress in database design and this has
now consider a stable discipline, with its own methods and techniques. Due to
the growing acceptance of databases by the industry and the
government in the commercial sphere, and to a variety of scientific applications and
techniques, database design plays a central role in employment
of the information resources in most organizations. The design of
databases have become part of the general training of the
computer scientists, at the same level as the ability to build algorithms using a
conventional programming language.

The last two decades have been characterized by strong growth in

the number and importance of database applications. The databases
Data are essential components of information systems, used
routinely on all computers [...]. The design of databases has
converted into a popular activity, developed not only by professionals but
also by non-specialists.

At the end of the 1960s, when databases first entered

Once in the software market, database designers acted
as craftsmen, with very primitive tools: block diagrams and
record structures were the common formats for specifications, and the
database design was often confused with the implementation of the
databases. This situation has now changed: the methods and models of
database designs have evolved parallel to the progress of the
technology in database systems. We have entered the era of
relational database systems, which offer powerful languages for
consultation, tools for the development of applications and user-friendly interfaces with
users. Database technology already has a theoretical framework that
includes the relational data theory, query processing and optimization,
concurrency control, transaction management and recovery, etc.

As database technology has advanced, so have

developed the methodologies and design techniques. A consensus has been reached,
for example, about the decomposition of the design process into phases, about the
main objectives of each phase and the techniques to achieve them
objectives.
 "Desafortunadamente, las metodologías de diseño de bases de datos no
they are very popular; most organizations and designers
individuals have very little trust in the methodologies to carry out the design and
this is often considered one of the main causes of failure in
development of information systems. Due to the lack of approaches
structured for database design, the often underestimated
time or the resources needed for a database project, the bases
data is inadequate or inefficient in relation to the demands of the
application, the documentation is limited and maintenance is difficult.
Many of these problems are due to a lack of clarity that allows
understand the exact nature of the data, at a conceptual and abstract level. In
In many cases, the data is described from the beginning of the project in terms
regarding the final storage structures; weight is not given to an understanding
of the structural properties of the data that is independent of the
details of the realization.
Database schema

The schema of a database describes

the structure of a database, in a formal language supported by a
Database Management System (DBMS). In a database
Relational, the Schema defines its tables, its fields in each table and the
relationships between each field and each table.

The schema is generally stored in a Data Dictionary.

Although it is common for the schema to be defined in a database language,
the term is often used to refer to a graphic representation of the
database structure.

Database paradigms.

Relational, it is the foundation of everything. The most studied, marketed model and
used. Not for that the best, but certain aspects (being in the moment
just, in the right place) have made it this way. In short,
Currently, talking about databases is talking about relational databases. But everything is...
changing, if not I wouldn't write this post really. If you don't know what the model is
relational, it means that you do not know what a database is, so I don't think you understand
the rest of the things I'm going to tell you and I don't even know why you're reading this long text, but
good.

Object-oriented, if all our applications are using objects, it is nonsense

want to keep the relational model underneath, right? There are different ORMs
that allows to bridge that immense gap between an object model and the
relational model, but if we can do without it, what better than our
Does the DBMS understand us directly and store objects directly? There are certain
quite striking things in a BDOO, such as not needing to have keys
Primaries, or the foreign keys are now really references. One could speak
a lot about this topic, but to summarize, a BDOO is simply our
persistent made objects.

Active, an active DBMS is one that, under certain conditions, and in a manner
automation executes previously specified actions, all without
user intervention. That is to say, a kind of DB + super-triggers (DB
Relational with triggers is not an active database). It can be subdivided into two models.
what the they constitute:
* Knowledge model: specifies the rules of the system, in summary they would be
tuples (Event, Condition, Action).
Execution model: is responsible for monitoring the situation and
manage behavior. Come on, the boss who tells you what to do and how.

DisStrategies en
o Conceptual

Eldi seño The conceptualization of a database is an iterative process.

of refinementnsuccessive. The foundations of a design methodology
d Iwoudl no
consist of primitive refinements of the design
d eno y t strategies.
Within the primitives, we have two groups: the top-Down (there are 8) and the
button-up (there are 5). The sets of primitives can have some
desirable properties such as completeness and nominalism.
, we have four: top-down, bottom-up, by
how mucha glasseststrategies
central concepts o outward) and mixed. (See copies of the book
BCN 92 for loss.) detail

Adicionalmente, the ERE model offers some heurísticasde design, for

to decide e the following high rnatives

Entity or Attribute?
In the example of the service company ee
lcc
rtih
t,epaymenh
tead
n
ile
can be presented
e as an attribute of the service contract or
as an entity associated with the contract.

Generalization or Attribute?
If in the previous example it is decided to represent the payment title
like a entity, then to indicate that the payees
they can be a person or a person jlegal, it can be
use a simple generalization nte
on o put an attribute that
indicate the type of payment title in that entity.

¿Compound attribute or Conjun to simple attributes?

Entity or Interrelation?
If the concept is very important
n in the
scheme and goa being related to other concepts is preferable
representnt a in the notion of payment, for example,
o cto can
it can be interrelation ión between a client and a product
being an entity that is associated with the client, as it is the one who pays y that
associates with the product because it is what youtap
see.
 The creators of lametodolo gía OMTtam bién they give some suggestions
rebuild the data model. These are:

Classes, associations, and inheritance should not be written "in a crazy manner."
First, it is necessary to understand the problem and the content of the model.
objects are obtained according to their relevance in the solution to
problem.

2. Create a simple model, avoid unnecessary complications.

3. Choose appropriate names very carefully. Names have a

powerful cconnotations implicit for everyone I that the
Lee. (This is one of the most difficult aspects to fíachieve.)
p

4. Do not hide references to other objects in pointers. Model

these refereferences with
o knowledge.

5. Do not try to place perfect cordialities too early.

6. Do not place the association attributes in one of the classes.

7. Use qualified associations when possible.

8. Building a correct object model requires reviews and several

iterations, it never goes well the first time.

9. Have others review your model.

10. Always document your object model, the diagram is not enough.
A guide to the model is needed and an explanation of why certain decisions were made.
decisions. These explanations clarify the model.

11. Do not feel that you must use all the object modeling primitives.
Not all problems need them all. Use only what you need and do.
a your model expressive y car explanatory
Unified Conceptual Model
OO techniques use the same conceptual models for analysis,
design and construction. The technology of BDOO takes a step further towards the
unification, the conceptual model of the OO database is the same as that of the rest of
world OO, instead of using independent relational tables like SQL.
The use of the same conceptual model for all aspects of development
simplify this, particularly with OO CASE tools; improve it
communication between users, analysts, and programmers, in addition to reducing
the possibilities of error.

Strategies for developing an object-relational database

Several providers of relational databases are trying

develop an object-relational solution. The different strategies used by each
Providers have their advantages and disadvantages.

The basic strategies are as follows:

a. Join an existing object-relational manager to a relational manager

b. Write a new manager from scratch
c. Iteratively improve an existing manager by incorporating
de nuevas funciones
d. Union of two products
The attempt to integrate two existing products offers the advantage of
provide a quick short-term solution. A solution can be created quickly.
passage between the two managers to allow transparent access between
both servers. However, one manager linked to another is equivalent to building
a bridge between a car and a vessel, waiting for both
they can interact. On one hand, there is the functionality of both
managers, but on the other hand, only one can be used effectively at the same
time.
It will take several years of integration before the two servers
they can effectively utilize their respective functionality at an acceptable level
of performance. This approach has a high probability of 'breaking' the
existing applications designed to work with one of the two
products.
g. Escribir un gestor a partir de cero
The creation of a completely new object-relational manager offers the
attractive of an elegant and tailored solution. Naturally, to write
 a database manager requires several years of work
development and this option is not attractive for this reason.
i. Perfecting an existing relational database server
This solution offers clearer advantages. The existing technology of the
relational databases can be enhanced progressively to
existing applications that depend on relational storage. It is
that's why existing applications can coexist with new ones
object-oriented applications. In addition, the new representations of
objects can leverage and utilize reliability, scalability, security and
optimization of queries that are already incorporated into the database server
data.

The evolutionary migration of an existing system is the safest option.

Although this approach is preferred and offers many advantages, it has a
inconvenience: it takes several years and several iterations to achieve it
product. Oracle has been working since 1992 to define and implement a
functionality of objects and integrate it into Oracle Server products, and will continue
refining the design process in the next versions of Oracle Server for
perfect the requirements of an object-relational database.

Conceptual Schema

The first step in designing a database is the production of

conceptual scheme. Usually, several schemes are constructed.
conceptual, each one to represent the different visions that users
they have the information. Each of these visions usually correspond to the
different functional areas of the company such as, for example, production,
sales, human resources, etc.

These visions of information, called views, can be identified from

various forms. One option is to examine the data flow diagrams,
that may have occurred previously, to identify each of the
áreas funcionales. La otra opción consiste en entrevistar a los usuarios, examinar
the procedures, the reports, and the forms, as well as observe the
functioning of the company.

A los esquemas conceptuales correspondientes a cada vista de usuario se les

denominates local conceptual schemes. Each of these schemes is
composed of entities, relationships, attributes, attribute domains and
identifiers. The conceptual schema will also have documentation, which
will be occurring during its development. The tasks to be performed in the design
the following are conceptual:

1. Identify the entities.

2. Identify the relationships.

3. Identify the attributes and associate them with entities and relationships.

4. Determine the domains of the attributes.

5. Determine the identifiers.

6. Determine the hierarchies of generalization (if any).

7. Draw the entity-relationship diagram.

8. Review the local conceptual scheme with the user.

The Object Relational Technology

Motivation

The introduction to this topic could have been the introduction to this.
subject, as we are going to motivate the need to model data
complexes that require other modeling paradigms. However, the
the course is naturally divided in two parts, on one hand the aspects
methodological aspects of conceptual modeling where emphasis is placed on that stage
of database design, and on the other hand the technology that can support the
implementation of the conceptual scheme.

The relational model has been sufficient for traditional applications.

commercial or business, these applications are characterized by handling data
very simple in large volumes. Simple data generally refers to
alphanumeric data that can be fairly accurately and easily,
represented on a computer. These applications have evolved in
regarding its handling needs, and storage and analysis of
historical data in what has been called 'data warehouses' and 'OLAP (on-
line analytical processing)
 Let's suppose an application where stories want to be recorded.
medical professionals of the peace- hundreds from a clinic or an integrated medicine center.
If you want to store alphanumeric data of the patients, such as for
example, your personal data, list of allergies you suffer from, family history of
diseases, surgical treatments received, and results of exams
blood, the ER-E model is sufficient, and the conceptual schema can be
efficiently implement in a handler that follows the relational model. Without
embargo, if history medical includes also: images of resonance
magnetic knee of the patient, video of some operation, photos of some
organ or chromosomes found as a result of an amniocentesis,
with annotations from the doctors, the ER-E and OMT models cease to be
sufficiently expressive, and the relational model it is completely
inconvenient, as it lacks proper structure and operations to manage
those data.

There are many applications with similar needs to the application

medical described above, for example, those of CAD/CAM, the systems of
Geographic information, multimedia databases, among others.

A first approach to this problem was to extend the

relational model (in theory) to accommodate these new data and their
manipulation needs, which led to extensible databases,
that proposed models with extensions to the relational to accommodate other types
of data and its operations. One of the first implementations of these
The idea was the Postgres manager (Stonebraker 1987), which still exists, with the
new name of PostgresSQL and it is one of the most free software products
robust in the database area.

At the same time, there were researchers in the area of object-oriented guidance.
defining object-oriented databases, as the OO paradigm is
naturalmente extensible, y con ello se podían representar esos datos e incluir
its operations encapsulated in the same notion of object. From these efforts
several generations of software for managing databases were born
object-oriented, known as OODBMS.

Another school of thought proposed to free the relational model from

the restriction that the domains of the attributes be atomic, so that
the relationships did not have to be in 1NF (first normal form) and were called
"non-festival normal form relationships" or NFNF or N F 2. Carrying this notion
to the extreme, a table could be defined with attributes whose values
they could be complete tables. For example, a table can be defined
DEPARTAMENTO con cinco atributos: código-D, nombre-D, jefe-D, Empleados
and Projects, where the Employee attribute takes values, tables with two
attributes name and address of the employee, and the attribute Projects is another
tabla, con atributos nombre- Proyecto y presupuesto.

Extensible databases evolved into what we know today.

it is called object-relational technology (OR), in which
they combine the notions of extensibility, object-oriented programming, and in some
cases up to nested tables.

In this course, we will do a brief historical review of the advancements.

that led to OR technology and we focused on that technology to
implement our conceptual schemes as a current alternative,
practical and valid for the use of an OODBMS.

Definitions

The object-oriented paradigm was developed in the areas of

programming languages and software engineering. In a language of
object-oriented programming, objects exist only during execution
of the program that creates them. On the other hand, in a database oriented by
objects, objects are created, they can be persistent and can be shared
among several programs. Therefore, object-oriented databases
they store persistent objects in secondary storage and support the
share objects between different applications.

The OODBMS are the result of integrating database technology.

with him for- dignified OO. To support persistent objects is necessary
add to this paradigm, database handler mechanisms,
such as data indexing, concurrency control, and handling
transactions.

Since the late 1980s, OODBMS have been built,

In just a few years, three generations of these products were developed.
first generation of OODBMS dates back to 1986, when the French company
Raphael introduced G-Base to the market. In 1987, the US bell
Serbio Corporation introduced Festone. In 1988, Ontological introduced Base and
Symbolic introduced Estatics. The common goal of all these developments was
give persistence to the object languages used in artificial intelligence.
These were independent systems, based on proprietary languages, that did not
they did not use any standard industrial platform. The systems built with
these products were located in the research departments of large
companies were built and about 500 were constructed.

The second generation of OODBMS began in 1989 with the release

of the product Untos by the company of the same name. Untos was followed by the
productos: ObjectStore (de Object Design), Objectivity/DB (de Objectivity), y
Versant ODBMS (from Versant Object Technology). These systems already used the
client/server architecture and they had a common platform: C++, X Windows and
UNIX stations.

Atasca was the first product of the third generation of OODBMS and
was released in August 1990 (just a few months after the products
of the second generation). This product was the commercial version of Orion,
MCC project (Microelectronics and Computer Corporation), institute of
research funded by American hardware manufacturing companies.
Los otros productos de esta generación eran O2, producido por la empresa
French Altaír, and Sitges, developed internally by Texas Instruments.

The third generation OODBMS products had characteristics

more advanced and had data definition and manipulation languages that
they were object-oriented and computationally complete.

In this environment, the development of many systems by

small businesses, these systems were revolutionary regarding the
Existing DBMSs were built from scratch with a very different foundation.
and with different data models. At that moment, the need was felt to
at least define what an OODBMS was and Atkinson wrote in 1989 what it was
called the Manifesto of Object-Oriented Database Systems,
which described the main characteristics of a system for
to be able to qualify as OODBMS.

Other characteristics of this time were: that these systems did not have
a common data model had been used only in applications
experimental. The lack of a standard for object databases was
a very important limitation of its acceptance in the market and on the other hand,
one of the secrets of RDBMS was precisely the existence of a
standard. In response to this, ODMG (Object) was formed in the summer of 1991.
Database Management Group) a consortium of companies (almost all of which
developed OODBMS), to try to provide a standard. ODMG was
affiliated with OMG (Object Management Group), established in 1989 and whose
the main contribution was the CORBA architecture for interoperability
distributed object systems. ODMG produced the first standards in
1993, they were: ODMG Object model, which defines the data model of the
object-oriented databases; ODL (Object Definition Language) which is
the DDL to define a schema in this data model; OQL (Object Query Language)
Language) that is a declarative language, inspired by SQL, for making the
correspondence between the concepts of the data model for OODB and the
languages considered in the standard and to define as the ODMG objects
they could be accused and manipulated by these languages (C++, Smalltalk, LISP,
Java)

Below we list in order the most important OODBMS of

market.

ORION/Atasca (name of the commercial version starting in 1990)

MCC Austin, Texas. Won Kim developed it, the first product was built.
since

1985 to 1989. Three generations of this product have been developed.

O2 (Altaír Consortium, 1986-1991)

It is described in a book: 'The Story of O2' (Bancaron 1992). They emphasized more.
in programming languages than in architecture.

Festone (1987)

It is the oldest commercial product that is available today. Extend

Sum- lethal in a database system. It has been the most visible of all, today.
There are two versions Festone/S (Smalltalk version) and Festone/J (Java version).

IRIS/Open (1989)
HP research prototype follows the functional model.

Base/Untos (1988)

Proprietary languages shifted to C++. It is fully distributed.

ObjectStore (1989)

It supports XML documents.

POET (1999)

C++ and Java. With its Content Management Suite, it supports XML documents and
SGML.

The fundamental concepts of the object-oriented paradigm are:

Objects

OID (object id). Equality by identity (identical): if they are the same object, it is
to say, they have the same identifier. Equality by value (equal): two objects are
they are equal if their states are recursively equal.

State of an object: values of the object's properties can change

in time. Properties: attributes and interrelations with other objects.

Behavior: specified by the operations that can be executed

on the object or about the object, and they possibly act on the state of the object.
Classes: all objects of the same type have the same set of
properties and operations. A type of object is defined through a class.
Extinct from a class: all the objects that belong to it.

Inheritance: by subtypes, by implementation, and by inclusion.

Object-Relational Managers

Unlike the OOBDMS which have a revolutionary approach, the

Object-Relational Database Management Systems (ORDBMS) are a
evolution of RDBMS, as they integrate objects into the relational data model
and extend existing RDBMS with features of the object-oriented paradigm
by objects. In the early 90s, the two approaches came into conflict, the OO
they proposed extensions to programming languages with OO, and those of
another side, the hybrid approach, proposed starting from the databases
relational and add OO extensions.

The idea of ORDBMS dates back to 1990 with the publication of the 'Tirad'
Database System Manifesto by Stonebraker. The basic premise of
this manifesto is that the new (third) generation of database handlers
data, they should be able to handle objects and rules, and they should be
compatible with the second generation handlers, that is, the
relational. In that same year, Anisal, Inc., founded by Won Kim, produced
a relational object manager, the Anisal, which used SQL/X, an extension of
SQL-92 as a database language. During that decade, other
companies that started, developed relational object products, such as
Ilustra and Omnisciente. By 1996, Informe buys Ilustra and all the greats
database management system producers, namely, Súbase, IBM, and Oracle,
they began working on object-relational products. That same year they
achieved a consensus regarding the particularities of the object-relational model
which were reflected in the SQL-3 standard and all the players in the database world
of data, they adopted it, each of them has released their product object
relational.

Los sistemas OR son relacionales porque soportan SQL, y son OO porque

they support complex data. If we consider the complexity in the data and the
complexity in the queries and we combine them in two perpendicular axes,
we obtain a matrix with four quadrants, namely: (Nóvate 2000 and
Stonebraker 1999

(I) simple data, simple queries (text editors, spreadsheet style

Excel, file system).

(II) simple data, complex queries (RDBMS).

(III) complex data, simple queries (some OODBMS, Choros, system

of image processing).

(IV) complex data, complex queries (ORDBMS).

At the end of the 1990s, OODBMS and ORDBMS stopped

to be in conflict, when the DBMS functions offered by the improved.
OODBMS improved their facilities to support a query language.
declarative (with the definition of OQL which is very similar to SQL-3). The
the main differences in these products are currently concentrated in the
following aspects:

OODBMS provide persistence for the objects created with the

OO languages, such as Java, C++, and Smalltalk; programmers define classes and
they create objects of those classes, and with the DBMS mechanisms they have,
they allow storing these objects and sharing them, therefore, the integration with
these languages are transparent. However, in ORDBMS a is introduced
Separate API (based on SQL) to manipulate the stored data,
class definitions should be "mapped" to the supported data types by the
database system.

At the architectural level, OODBMS are client-centered.

they manage an object cache on client machines and allow the
navigation among related objects, which is very appropriate for certain
applications. On the other hand, ORDBMS have a more focused approach on
the server, which is more appropriate to satisfy many queries
concurrent to the data.

Essentially, the concepts of object-relational technology are:

User-defined abstract data types (ADTs).

Complex types (or structured, or aggregated), defined based on types
atomic with the use of type constructors to create: sets,
tuples, arrangements, sequences, among others.

Inheritance: definition of data types as subtypes of others.

Reference types. Pointers to objects of another type.

Blobs (were the only thing RDBMS had).

These new types of data need new manipulation functions.

These functions are:

User-defined methods: methods associated with the Tas.

Operators for complex types (structured or aggregated): for example, the

The contractor set has the methods: belongs-to, subset of, equality of
sets, intersection, union, and difference of sets.
 Conclusion

Database design is broken down into three stages: design

conceptual, logical design, and physical design. Conceptual design is the process by which
how to build a model of the information used in a company or
organization, regardless of the DBMS that will be used for
implement the system and the computers or any other
physical consideration.

A conceptual model is a set of concepts that allows for description.

the reality through linguistic and graphic representations. The models
conceptual models must possess a series of properties: expressiveness, simplicity,
minimalism and formality.

The most widely used conceptual model is the entity-relationship model, which
has the following concepts: entities, relationships, attributes, domains of
attributes, identifiers, and generalization hierarchies.

In the methodology of conceptual design, a scheme is constructed.

conceptual local for each view of each user or group of users. In the design
a logical local schema is obtained for each local conceptual schema.
These logical schemes are integrated later to form a logical scheme.
a global view that represents all the perspectives of the different users of the company.
Finally, in physical design, the implementation of the database is constructed.
sobre un SGBD determinado. Ya que este diseño debe adaptarse al SGBD, es
it may be necessary to introduce changes in the logical schema to improve the
physical performance.

Each user view encompasses the data that a user handles for
carry out a specific task. Normally, these views correspond to
the different functional areas of the company, and they can be identified by examining
data flow diagrams or interviewing users, examining the
procedures, reports and forms, and observing the operation of the
company.

Each local conceptual scheme is formed by entities, relationships,

attributes, attribute domains, identifiers, and there may also be hierarchies
of generalization. In addition, these schemes are completed by documenting them in the
data dictionary.

Bibliography

The aspects of the entity-relationship model where they are incorporated

characteristics of the extended entity-relationship model, such as hierarchies
Generalization is well addressed in the texts by Batini, Ceri, and Navathe.
(1994) and Connolly, Begg and Strachan (1996). The latter are the ones that best
they present the methodology of conceptual design, providing all kinds
tricks to identify each of the components of a scheme
conceptual.

Database Modeling Paradigms I. CI5311. Class notes Prof.

Soraya Abad Mota

Internet inquiries:

University of Oviedo. Development of DBMS in Oviedo3

www.Uniovi.es/~oviedo3/belen/jindbd96.html.6/Nov/1999

IT Bulletin. Overview of the DBOO

http://www.uaemex.mx/publica/informatia/boletin/panorama.html 3/Nov/99

Related jobs

http://www.infoseek.com 26/Dic/99

Atkinson Manifesto. 'Object-Oriented Database Management Systems'

http://www.cs.cmu.edu/afs/cs.cmu.edu/user/clamen/OODBMS/Manifesto/htM
manifesto/Manifesto.html10/Dec/99
Read more:

http://www.monografias.com/trabajos5/tipbases/tipbases.shtml#ixzz2hlxYNY
00