Entidade Associação

Sistemas Gestores de Bases de Dados
Apresentação da Disciplina
&
Introdução aos SGBD
David Aveiro - UMa

Programa
 Tópicos a abordar:
 Introdução aos SGBD
 Modelo entidade-associação (E-A)
 Modelo e álgebra relacional
 Conversão do Modelo E-A em esquema relacional
 Linguagem SQL
 Normalização
 Ficheiros e indexação
 SGBD MySQL e pacote XAMPP para desenvolvimento de
aplicações, PHP
 Apresentações dos alunos relativas ao trabalho de pesquisa:
 Vistas, Alternativa ao modelo E-A: Object Role Modeling (ORM),
Transacções, Gestão de concorrência, Recuperação de falhas,
Arquitecturas de SGBDs, Clustering de SGBDs, Análise comparativa
dos melhores SGBDs gratuitos da actualidade, Storage engines do
MySQL, Optimização do MySQL, Sistemas noSQL.
Sistemas Gestores de Bases de Dados - David Aveiro - UMa 2

Avaliação
 Todas as componentes e os seus elementos (cada frequência e cada
trabalho) têm nota mínima obrigatória de 10.00, ou seja e por exemplo,
9.45 ou 9.90 leva a reprovação. Apenas a componente teórica pode ser
recuperada em época de recurso ou especial.
 Componente teórica - 40% (individual)
 Frequências - 20% + 20%
– possibilidade de realização de cada frequência com consulta
- para quem entregar previamente uma síntese de 1 página
da matéria teórica alvo dessa frequência, de acordo com as
regras publicadas, realizada, individualmente, por cada aluno
e entregue e avaliada como parte da frequência (5% do valor
da mesma)
– é possível recuperar de classificação negativa, das duas
frequências, ou apenas a uma, em época de recurso ou
especial

Avaliação
 Componente prática - 60% (em grupos de 3 alunos)
 Trabalho de Pesquisa (TP) - 25%
 Artigo escrito resultante da pesquisa de um tema inserido no
programa da disciplina - 7,5%
 Defesa final do trabalho através da apresentação em slides do
respectivo artigo e resposta a questões sobre o mesmo – 7,5%
 Avaliação contínua - 10%
 Trabalho de Desenvolvimento de uma Base de Dados (TDBD) -
35%
 Trabalho envolvendo modelação conceptual de uma BD e
respectiva implementação utilizando PHP+MySQL - 12,5%
 Defesa final do trabalho através da apresentação das
funcionalidades implementadas e resposta a questões sobre a
implementação - 12,5%
 Avaliação contínua - 10%

Avaliação contínua
 Assiduidade obrigatória na maioria das aulas práticas para avaliação
contínua dos trabalhos
 Serão realizadas questões aos alunos em várias aulas práticas,
sobre o trabalho prático por eles recentemente realizado, bem como
enquadramento do mesmo na respectiva matéria teórica. NOTA:
caso algum aluno trabalhador estudante não possa,
comprovadamente, comparecer nas aulas práticas, será marcado,
caso a caso, uma hora para a respectiva avaliação em horário de
atendimento a definir.

E-mail
 Endereço de e-mail principal: daveiro@staff.uma.pt
 ATENÇÃO:
 em todos os contactos por email colocar no início do assunto o
prefixo: SGBD20202021:
 enviar mensagens de e-mail para este endereço apenas
respeitantes a situações de cariz individual ou muito específico
 todas as outras questões relacionadas com os trabalhos devem
ser colocadas num dos fóruns específicos da disciplina para que
todos possam ver a dúvida e a resposta dada

Informação Útil
 Atendimento
 Sala: 2.90
 Horário de atendimento: disponível brevemente no Moodle.
 Página Internet da cadeira
 https://moodle.cee.uma.pt/2021/course/view.php?id=57
 Chave de acesso para inscrição (obrigatória):
 20dbms21

Bibliografia
 Bibliografia
 Slides da Cadeira
 Livro
Database System Concepts (7ª ed.)
A. Silberschatz, H. Korth, S. Sudarshan

Grupos e Inscrição nas Aulas Práticas
 Comunicado por e-mail/Moodle

Chapter 1: Introduction
Adapted from: Database System Concepts - 5th Edition
©Silberschatz, Korth and Sudarshan
David Aveiro - UMa

Chapter 1: Introduction
 Purpose of Database Systems
 View of Data
 Database Languages
 Relational Databases
 Database Design
 Object-based and semistructured databases
 Data Storage and Querying
 Transaction Management
 Database Architecture
 Database Users and Administrators
 Overall Structure
 History of Database Systems

Database Management System (DBMS)
 DBMS contains information about a particular enterprise
 Collection of interrelated data
 Set of programs to access the data
 An environment that is both convenient and efficient to use
 Database Applications:
 Banking: all transactions
 Airlines: reservations, schedules
 Universities: registration, grades
 Sales: customers, products, purchases
 Online retailers: order tracking, customized recommendations
 Manufacturing: production, inventory, orders, supply chain
 Human resources: employee records, salaries, tax deductions
 Databases touch all aspects of our lives

Purpose of Database Systems
 In the early days, database applications were built directly on top of
file systems
 Drawbacks of using file systems to store data:
 Data redundancy and inconsistency
 Multiple file formats, duplication of information in different files
 Difficulty in accessing data
 Need to write a new program to carry out each new task
 Data isolation — multiple files and formats
 Integrity problems
 Integrity constraints (e.g. account balance > 0) become
“buried” in program code rather than being stated explicitly
 Hard to add new constraints or change existing ones

Purpose of Database Systems (Cont.)
 Drawbacks of using file systems (cont.)
 Atomicity of updates
 Failures may leave database in an inconsistent state with partial
updates carried out
 Example: Transfer of funds from one account to another should
either complete or not happen at all
 Concurrent access by multiple users
 Concurrent accessed needed for performance
 Uncontrolled concurrent accesses can lead to inconsistencies
– Example: Two people reading a balance and updating it at the

same time
 Security problems
 Hard to provide user access to some, but not all, data
 Database systems offer solutions to all the above problems

Levels of Abstraction
 Physical level: describes how a record (e.g., customer) is stored.
 Logical level: describes data stored in database, and the relationships
among the data.
type customer = record
customer_id : string;
customer_name : string;
customer_street : string;
customer_city : integer;
end;
 View level: application programs hide details of data types. Views can
also hide information (such as an employee’s salary) for security
purposes.

View of Data
An architecture for a database system

Instances and Schemas
 Similar to types and variables in programming languages
 Schema – the logical structure of the database
 Example: The database consists of information about a set of customers and
accounts and the relationship between them)
 Analogous to type information of a variable in a program
 Physical schema: database design at the physical level
 Logical schema: database design at the logical level
 Instance – the actual content of the database at a particular point in time
 Analogous to the value of a variable
 Physical Data Independence – the ability to modify the physical schema without
changing the logical schema
 Applications depend on the logical schema
 In general, the interfaces between the various levels and components should be
well defined so that changes in some parts do not seriously influence others.

Data Models
 A collection of tools for describing
 Data
 Data relationships
 Data semantics
 Data constraints
 Relational model
 Entity-Relationship data model (mainly for database design)

Data Manipulation Language (DML)
 Language for accessing and manipulating the data organized by the
appropriate data model
 DML also known as query language
 Two classes of languages
 Procedural – user specifies what data is required and how to get
those data
 Declarative (nonprocedural) – user specifies what data is
required without specifying how to get those data
 SQL is the most widely used query language

Data Definition Language (DDL)
 Specification notation for defining the database schema
Example: create table account (
account-number char(10),
balance integer)
 DDL compiler generates a set of tables stored in a data dictionary
 Data dictionary contains metadata (i.e., data about data)
 Database schema
 Data storage and definition language
 Specifies the storage structure and access methods used
 Integrity constraints
 Domain constraints
 Referential integrity (references constraint in SQL)
 Assertions
 Authorization

Relational Model
Attributes
 Example of tabular data in the relational model

A Sample Relational Database

SQL
 SQL: widely used non-procedural language
 Example: Find the name of the customer with customer-id 192-83-7465
select customer.customer_name
from customer
where customer.customer_id = ‘192-83-7465’
 Example: Find the balances of all accounts held by the customer with
customer-id 192-83-7465
select account.balance
from depositor, account
where depositor.customer_id = ‘192-83-7465’ and
depositor.account_number = account.account_number
 Application programs generally access databases through one of
 Language extensions to allow embedded SQL
 Application program interface (e.g., ODBC/JDBC) which allow SQL
queries to be sent to a database

Database Design
The process of designing the general structure of the database:
 Logical Design – Deciding on the database schema. Database design

requires that we find a “good” collection of relation schemas.
 Business decision – What attributes should we record in the
database?
 Computer Science decision – What relation schemas should we
have and how should the attributes be distributed among the various
relation schemas?
 Physical Design – Deciding on the physical layout of the database

The Entity-Relationship Model
 Models an enterprise as a collection of entities and relationships
 Entity: a “thing” or “object” in the enterprise that is distinguishable
from other objects
 Described by a set of attributes
 Relationship: an association among several entities
 Represented diagrammatically by an entity-relationship diagram:

Object-Relational Data Models
 Extend the relational data model by including object orientation and
constructs to deal with added data types.
 Allow attributes of tuples to have complex types, including non-atomic
values such as nested relations.
 Preserve relational foundations, in particular the declarative access to
data, while extending modeling power.
 Provide upward compatibility with existing relational languages.

Storage Management
 Storage manager is a program module that provides the interface
between the low-level data stored in the database and the application
programs and queries submitted to the system.
 The storage manager is responsible to the following tasks:
 Interaction with the file manager
 Efficient storing, retrieving and updating of data
 Issues:
 Storage access
 File organization
 Indexing and hashing

Query Processing
1. Parsing and translation

2. Optimization
3. Evaluation

Query Processing (Cont.)
 Alternative ways of evaluating a given query
 Equivalent expressions
 Different algorithms for each operation
 Cost difference between a good and a bad way of evaluating a query can
be enormous
 Need to estimate the cost of operations
 Depends critically on statistical information about relations which the
database must maintain
 Need to estimate statistics for intermediate results to compute cost of
complex expressions

Transaction Management
 A transaction is a collection of operations that performs a single
logical function in a database application
 Transaction-management component ensures that the database
remains in a consistent (correct) state despite system failures (e.g.,
power failures and operating system crashes) and transaction failures.
 Concurrency-control manager controls the interaction among the
concurrent transactions, to ensure the consistency of the database.

Database Architecture
The architecture of a database systems is greatly influenced by

the underlying computer system on which the database is running:
 Centralized
 Client-server
 Parallel (multi-processor)
 Distributed

Database Users
Users are differentiated by the way they expect to interact with
the system
 Application programmers – interact with system through DML calls
 Sophisticated users – form requests in a database query language
 Specialized users – write specialized database applications that do
not fit into the traditional data processing framework
 Naïve users – invoke one of the permanent application programs that
have been written previously
 Examples, people accessing database over the web, bank tellers,
clerical staff

Database Administrator
 Coordinates all the activities of the database system; the
database administrator has a good understanding of the
enterprise’s information resources and needs.
 Database administrator's duties include:
 Schema definition
 Storage structure and access method definition
 Schema and physical organization modification
 Granting user authority to access the database
 Specifying integrity constraints
 Acting as liaison with users
 Monitoring performance and responding to changes in
requirements

Overall System Structure

History of Database Systems
 1950s and early 1960s:
 Data processing using magnetic tapes for storage
 Tapes provide only sequential access
 Punched cards for input
 Late 1960s and 1970s:
 Hard disks allow direct access to data
 Network and hierarchical data models in widespread use
 Ted Codd defines the relational data model
 Would win the ACM Turing Award for this work
 IBM Research begins System R prototype
 UC Berkeley begins Ingres prototype
 High-performance (for the era) transaction processing

History (cont.)
 1980s:
 Research relational prototypes evolve into commercial systems
 SQL becomes industrial standard
 Parallel and distributed database systems
 Object-oriented database systems
 1990s:
 Large decision support and data-mining applications
 Large multi-terabyte data warehouses
 Emergence of Web commerce
 2000s:
 XML and XQuery standards
 Automated database administration

Sistemas Gestores de Bases de Dados
Aula T01
Chapter 6: Entity-Relationship Model
Adapted from: Database System Concepts - 5th Edition
©Silberschatz, Korth and Sudarshan
David Aveiro - UMa

Chapter 6: Entity-Relationship Model
 Design Process
 Modeling
 Constraints
 E-R Diagram
 Design Issues
 Weak Entity Sets
 Extended E-R Features
 Design of the Bank Database

Design Alternatives
 Iterative decisions about representing “things”
 A good design
 Explores common aspects
 Keeps flexibility for the future
 A bad design
 Redundant
 Incomplete

Modeling
 A database can be modeled as:

 a collection of entities,
 relationship among entities.
 An entity is an object that exists (physically or not) and is distinguishable from
other objects.
 Example: specific person, company, event, plant
 Entities have specific attributes and values for each attribute
 Example: people have names and addresses
 An entity set is a set of entities of the same type (they share same properties)
 Example: set of all persons, companies, trees, holidays
 It is possible that they are not disjoint
 e.g. a person that is simultaneously a worker and a client
 From now on referred as entity (ENTIDADE) and the previous concept is
referred as an instance of (INSTÂNCIA DE) an entity

Entities customer and loan
customer_id customer_ customer_ customer_ loan_ amount
name street city number

Attributes
 An entity is represented by a set of attributes, that is descriptive properties

possessed by all members of an entity set.
Example:
customer = (customer_id, customer_name,
customer_street, customer_city )
loan = (loan_number, amount )
 Domain – the set of permitted values for each attribute
 Attribute types:
 Simple and composite (COMPOSTO) attributes
 Example: composite attribute: address
 Single-valued (UNI-VALOR) and multi-valued attributes
 Example: multivalued attribute: phone_numbers
 Derived attributes (can be computed from other attributes)
 Example: age, given date_of_birth

Composite Attributes

Relationship Sets
 A relationship is an association among several entities

Example:
Hayes depositor A-102
customer entity relationship set account entity
 A relationship set is a mathematical relation among n  2 entities, each taken
from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}
where (e1, e2, …, en) is a relationship

 Example:
(Hayes, A-102)  depositor
 From now on, we refer to
 a relationship set as a relationship (ASSOCIAÇÃO)
 a relationship as an instance of a relationship (INSTÂNCIA DE
ASSOCIAÇÃO)

Relationship borrower

Relationship (Cont.)
 An attribute can also be property of a relationship.

 For instance, the depositor relationship between entity customer and
account may have the attribute access-date

Degree (ARIDADE) of a Relationship
 Refers to number of entities that participate in a relationship.

 Relationship that involve two entities are binary (or degree two).
 Generally, most relationships in a database system are binary.
 Relationships may involve more than two entities.
 Example: Suppose employees of a bank may have jobs
(responsibilities) at multiple branches, with different jobs at
different branches. Then there is a ternary relationship
between entities employee, job, and branch
 Relationships between more than two entity are rare. Most
relationships are binary. (More on this later.)

Mapping Cardinality Constraints
 Express the number of instances to which another instance can be

associated via a relationship.
 Most useful in describing binary relationships.
 For a binary relationship the mapping cardinality must be one of the
following types:
 One to one
 One to many
 Many to one
 Many to many

Mapping Cardinalities
One to one One to many

Note: Some elements in A and B may not be mapped to any
elements in the other set

Mapping Cardinalities
Many to one Many to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
Keys for Entities
 A super key of an entity is a set of one or more attributes whose

values uniquely determine each entity.
 A candidate key of an entity is a minimal super key
 Customer_id is candidate key of customer
 account_number is candidate key of account
 Although several candidate keys may exist, one of the candidate
keys is selected to be the primary key.
 Situations to be careful
 Unique identifiers in a restricted environment
 e.g. international clients
 Attributes that can be subject of change
 e.g. merging of companies

Keys for Relationships
 The combination of primary keys of the participating entities forms a

super key of a relationship and describe an individual relationship
 (customer_id, account_number) is the super key of depositor
 We must consider the mapping cardinality of the relationship when
deciding what are the candidate keys
 Having (customer_id, account_number)  depositor
 If the relationship is of type (what does each mean?):
 Many to many: (customer_id, account_number)
 Many to one: (customer_id, account_number)
 One to many: (customer_id, account_number)
 One to one:
 (customer_id, account_number) or
 (customer_id, account_number)

E-R Diagrams
 Rectangles represent entities.

 Diamonds represent relationships.
 Lines link attributes to entities and entities to relationships.
 Ellipses represent attributes
 Double ellipses represent multivalued attributes.
 Dashed ellipses denote derived attributes.
 Underline indicates primary key attributes (will study later)

E-R Diagram With Composite, Multivalued, and
Derived Attributes

Relationships with Attributes

Roles (PAPÉIS)
 Entities of a relationship need not be distinct

 The labels “manager” and “worker” are called roles; they specify how
employee entities interact via the works_for relationship.
 Roles are indicated in E-R diagrams by labeling the lines that connect
diamonds to rectangles.
 Role labels are optional, and are used to clarify semantics of the
relationship

Cardinality Constraints
 We express cardinality constraints by drawing either a directed line (),

signifying “one,” or an undirected line (—), signifying “many,” between
the relationship set and the entity set.
 One-to-one relationship:
 A customer is associated with at most one loan via the relationship
borrower
 A loan is associated with at most one customer via borrower

One-To-Many Relationship
 In the one-to-many relationship a loan is associated with at most one

customer via borrower, a customer is associated with several (including
0) loans via borrower

Many-To-One Relationships
 In a many-to-one relationship a loan is associated with several (including

0) customers via borrower, a customer is associated with at most one
loan via borrower

Many-To-Many Relationship
 A customer is associated with several (possibly 0) loans via

borrower
 A loan is associated with several (possibly 0) customers via
borrower
 Which of the 3 alternatives makes sense?

Participation of an Entity in a Relationship
 Total participation (indicated by double line): every instance of an entity
participates in at least one instance of the relationship
 E.g. participation of loan in borrower is total
 every loan must have a customer associated to it via borrower
 Partial participation: some instances of entity may not participate in any
instance of the relationship
 Example: participation of customer in borrower is partial

Alternative Notation for Cardinality Limits
 Cardinality limits can also express participation constraints

E-R Diagram with a Ternary Relationship

Design Issues
 Use of entites vs. attributes

Choice mainly depends on the structure of the enterprise being
modeled, and on the semantics associated with the attribute in
question.
 Use of entities vs. relationships
Possible guideline is to designate a relationship to describe an
action that occurs between entities
 Binary versus n-ary relationships
Although it is possible to replace any nonbinary (n-ary, for n > 2)
relationship by a number of distinct binary relationship, a n-ary
relationship shows more clearly that several entities participate in
a single relationship.
 Placement of relationship attributes

Use of entites vs. attributes
 Given the entity
 employee(employee_id,
employee_name, …,
telephone_number)
 Could telephone be an entity?
 telephone(telephone_number
, location)
 It would imply the need of a
relationship emp_telephone
 Other attributes?

Use of entites vs. attributes
 Answer to the issue
 It depends on the domain and operations needed
 Avoid complexity
 Issues to take care (on E-R diagrams)
 Do not use the primary key of an entity as an attribute of another
entity
 Do not include the primary keys of the participating entities in a
relationship (they already are there implicitly)

Use of entities vs. relationships
 A loan is an entity or a relationship between client and branch?

Use of entities vs. relationships
 Problem: situation in which several clients ask for loans together
 It would imply data replication (redundancy)
 Answer to the issue
 Relationships with attributes are strong candidates for entities

Binary Vs. Non-Binary Relationships
 Some relationships that appear to be non-binary may be better represented

using binary relationships (we should use them as much as possibe)
 E.g. A ternary relationship parents, relating a child to his/her father and
mother, is best replaced by two binary relationships, father and mother
 Using two binary relationships allows partial information (e.g. only
mother being know)
 But there are some relationships that are naturally non-binary
 Example: works_on

Converting Non-Binary Relationships to
Binary Form
 In general, any non-binary relationship can be represented using binary relationships
by creating an artificial entity
 Replace R between entities A, B and C by an entity E, and three relationships:
1. RA, relating E and A 2.RB, relating E and B
3. RC, relating E and C
 Create a special identifying attribute for E
 Add any attributes of R to E
 For each instance of relationship (ai , bi , ci) in R, create
1. a new instance ei of the entity E 2. add (ei , ai ) to RA
3. add (ei , bi ) to RB 4. add (ei , ci ) to RC

Converting Non-Binary Relationships
(Cont.)
 Also need to translate constraints
 Translating all constraints may not be possible
 There may be instances in the translated schema that
cannot correspond to any instance of R
 Exercise: add constraints to the relationships RA, RB and
RC to ensure that a newly created entity corresponds to
exactly one entity in each of entities A, B and C
 We can avoid creating an identifying attribute by making E a
weak entity set (described shortly) identified by the three
relationships

Placement of relationship attributes
 Can make access-date an attribute of account, instead of a relationship attribute, if

each account can have only one customer
 That is, the relationship from account to customer is many to one, or
equivalently, customer to account is one to many

Placement of relationship attributes
 Place of attributes in a relationship
 On the entity “many” of a relationship
 One to many
 Many to one
 Or in any of the entities in an association
 One to one
 And what about many to many?
 The account is managed by several clients and we want to keep
information of who accessed the account
 We have to place the attributes in the association

Weak Entity
 An entity that does not have a primary key is referred to as a weak

entity
 The existence of a weak entity depends on the existence of a
identifying entity
 it must relate to the identifying entity via a total, one-to-many
relationship from the identifying entity to the weak entity
 Identifying relationship depicted using a double diamond
 The discriminator (or partial key) of a weak entity is the set of attributes
that distinguishes among all the instances of a weak entity.
 The primary key of a weak entity is formed by the primary key of the
strong entity on which the weak entity is existence dependent, plus the
weak entity's discriminator
 NOTA: hoje em dia obsoleto e não usar (aqui por razões históricas)

Weak Entity (Cont.)
 We depict a weak entity by double rectangles.

 We underline the discriminator of a weak entity with a dashed line.
 payment_number – discriminator of the payment entity
 Primary key for payment – (loan_number, payment_number)
 NOTA: hoje em dia obsoleto e não usar (aqui por razões
históricas)

Extended E-R Features: Specialization
 Top-down design process; we designate subgroupings within an entity

that are distinctive from other entities.
 These subgroupings become lower-level entities that have attributes or
participate in relationships that do not apply to the higher-level entity.
 Depicted by a triangle component labeled ISA (E.g. customer “is a”
person).
 Attribute inheritance – a lower-level entity inherits all the attributes and
relationship participation of the higher-level entity to which it is linked.

Specialization Example

Extended ER Features: Generalization
 A bottom-up design process – combine a number of entities that

share the same features into a higher-level entity.
 Specialization and generalization are simple inversions of each
other; they are represented in an E-R diagram in the same way.
 The terms specialization and generalization are used
interchangeably.

Specialization and Generalization (Cont.)
 Can have multiple specializations of an entity based on different

features.
 E.g. permanent_employee vs. temporary_employee, in addition to
officer vs. secretary vs. teller
 Each particular employee would be
 a member of one of permanent_employee or temporary_employee,
 and also a member of one of officer, secretary, or teller
 The ISA relationship also referred to as superclass - subclass
relationship

Design Constraints (RESTRIÇÕES) on a
Specialization/Generalization
 Constraint on which entities can be members of a given lower-level
entity.
 condition-defined
 Example: all customers over 65 years are members of senior-
citizen entity; senior-citizen ISA person.
 User-defined
 Examples: manager determines when worker goes from
temporary_worker to permanent_worker

Design Constraints on a
Specialization/Generalization (Cont.)
 Completeness constraint -- specifies whether or not an
instance of an entity in the higher-level entity must belong to at
least one of the lower-level entities within a generalization.
 total : an entity must belong to one of the lower-level
entities
 Example: conta tem mesmo de ser a prazo ou à ordem
 partial: an entity need not belong to one of the lower-level
entities
 Example: the worker that does not belong to a team

Aggregation
 Consider the ternary relationship works_on, which we saw earlier
 Suppose we want to record managers for tasks performed by an
employee at a branch
 NOTA: hoje em dia obsoleto e não usar (aqui por razões históricas)

Aggregation (Cont.)
 Relationship works_on and manages represent overlapping information

 Every manages relationship corresponds to a works_on relationship
 However, some works_on relationships may not correspond to any
manages relationships
 So we can’t discard the works_on relationship
 Eliminate this redundancy via aggregation
 Treat relationship as an abstract entity
 Allows relationships between relationships
 Abstraction of relationship into new entity
 Without introducing redundancy, the following diagram represents:
 An employee works on a particular job at a particular branch
 An employee, branch, job combination may have an associated manager

E-R Diagram With Aggregation

Summary of Symbols Used in E-R Notation

Summary of Symbols (Cont.)

E-R Design Decisions
 The use of an attribute or entity to represent an object.

 Whether a real-world concept is best expressed by an entity or a
relationship.
 The use of a ternary relationship versus a pair of binary
relationships.
 The use of a strong or weak entity.
 The use of specialization/generalization – contributes to modularity
in the design.
 The use of aggregation – can treat the aggregate entity as a single
unit without concern for the details of its internal structure.

Exemplo de Desenho
 Descrição do domínio
 1 - O banco está organizado em agências. Cada agência está
localizada numa cidade e é identificada por um nome único.

Exemplo de Desenho
 2 - Os clientes do banco são
identificados pelo seu
customer_id. O banco
guarda o nome do cliente e a
rua e cidade onde vive. Os
clientes podem ter contas e
podem contrair empréstimos.
O cliente pode estar
associado com um
funcionário em particular, na
qualidade de “gestor de
empréstimo” ou “gestor de
conta”.

Exemplo de Desenho
 3 - Os funcionários do banco
estão identificados por um
employee_id. A
administração do banco
guarda o nome e número de
telefone de cada funcionário,
os nomes dos dependentes
desse funcionário, e o
employee_id do gestor desse
funcionário. O banco também
regista a data de entrada do
funcionário ao serviço bem
como a respectiva duração.

Exemplo de Desenho
 4 - O banco oferece 2 tipos
de contas – à ordem e a
prazo. As contas podem ter
vários titulares e um cliente
pode ter várias contas. Cada
conta tem um número único.
O banco mantém um registo
do saldo, da última data de
acesso à conta, e do titular
que fez o acesso. Contas a
prazo têm um taxa de juro.
Contas à ordem têm um
limite de débito.

Exemplo de Desenho
 5 - Um empréstimo tem origem numa agência e pode ser contraído
por um ou mais clientes. O empréstimo é identificado por um
loan_id. O banco mantém um registo da quantia em dívida e dos
pagamentos do empréstimo identificados por um número
sequencial. A data e quantia de cada pagamento são registadas.

Exemplo de Desenho
 Descrição do domínio - associações
 borrower – muitos clientes para muitos empréstimos
 loan_branch – muitos empréstimos para uma agência
 loan_payment – muitos pagamentos para um empréstimo
 depositor – muitos clientes para muitas contas
 cust_banker – muitos clientes para um funcionário
 works_for – um gestor para muitos funcionários

E-R Diagram for a Banking Enterprise

Entidade Associação

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Entidade Associação

Enviado por

Direitos autorais:

Formatos disponíveis

Sistemas Gestores de Bases de Dados

David Aveiro - UMa

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 2

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 3

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 4

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 5

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 6

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 8

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 9

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 10

David Aveiro - UMa

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 12

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 13

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 14

– Example: Two people reading a balance and updating it at the

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 15

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 16

An architecture for a database system

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 17

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 18

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 19

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 20

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 21

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 22

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 23

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 24

 Logical Design – Deciding on the database schema. Database design

 Physical Design – Deciding on the physical layout of the database

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 25

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 26

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 27

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 28

1. Parsing and translation

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 29

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 30

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 31

The architecture of a database systems is greatly influenced by

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 32

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 33

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 34

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 35

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 36

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 37

David Aveiro - UMa

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 39

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 40

 A database can be modeled as:

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 41

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 42

 An entity is represented by a set of attributes, that is descriptive properties

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 43

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 44

 A relationship is an association among several entities

where (e1, e2, …, en) is a relationship

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 45

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 46

 An attribute can also be property of a relationship.

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 47

 Refers to number of entities that participate in a relationship.

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 48

 Express the number of instances to which another instance can be

Sistemas Gestores de Bases de Dados - David Aveiro - UMa 49

One to one One to many