E-R diagrams and normalisation · Diagramas E-R e normalização
| English | Português |
|---|---|
| entity-relationship diagram/ˈentɪti rɪˈleɪʃənʃɪp ˈdaɪəɡræm/ | diagrama entidade-relacionamento |
| normalisation/ˌnɔːməlaɪˈzeɪʃn/ | normalização |
| entity/ˈentɪti/ | entidade |
| cardinality/ˌkɑːdɪˈnælɪti/ | cardinalidade |
| one-to-many/wʌn tə ˈmeni/ | um-para-muitos |
| many-to-many/ˈmeni tə ˈmeni/ | muitos-para-muitos |
| link table/lɪŋk ˈteɪbl/ | tabela de ligação |
| normal forms/ˈnɔːml fɔːmz/ | formas normais |
| atomic/əˈtɒmɪk/ | atômica |
| transitive dependency/ˈtrænsɪtɪv dɪˈpendənsi/ | dependência transitiva |
Forty rows to change one phone number
- A school keeps its enrolments in one spreadsheet. Every row is one student on one course, and every row also carries the student's form tutor and the tutor's phone number.
- The tutor changes her number. Forty rows have to be edited. Thirty-nine are. For the rest of the year, one course list rings a stranger.
- Nothing was mistyped. The fault was in the design: a fact that belongs to the tutor was stored once per enrolment, so it could be true in one place and false in another.
- This lesson is the two design tools that prevent that: the entity-relationship diagram 实体关系图, which draws the structure, and normalisation 规范化, which removes the repetition.
Quarenta linhas para alterar um único número de telefone
- Uma escola mantém suas matrículas em uma planilha. Cada linha representa um aluno em um curso, e cada linha também contém o tutor da turma e o número de telefone do tutor.
- O tutor altera seu número. Quarenta linhas precisam ser editadas. Trinta e nove são. Para o restante do ano, uma lista de cursos liga a alguém desconhecido.
- Nada foi digitado incorretamente. A falha estava no projeto: um fato que pertencia ao tutor foi armazenado uma vez para cada matrícula, podendo estar correto em um lugar e errado em outro.
- Esta lição apresenta as duas ferramentas de projeto que evitam isso: o diagrama entidade-relacionamento 实体关系图, que desenha a estrutura, e a normalização 规范化, que remove a repetição.
Entity-relationship diagrams
- An entity-relationship diagram (E-R diagram) documents a database design: each entity 实体 is a rectangle, each relationship is a line between two rectangles, and the cardinality 基数 is marked at each end.
- In crow's-foot notation a single bar means "one" and a three-pronged foot means "many". Read each line in both directions: each customer places many orders; each order is placed by one customer.
- The diagram is drawn before any table is created, and the relationships on it become the foreign keys.
One rectangle per entity, one line per relationship
A bar for one, a foot for many
Diagramas entidade-relacionamento
- Um diagrama entidade-relacionamento (diagrama E-R) documenta o projeto de uma base de dados: cada entidade 实体 é um retângulo, cada relacionamento é uma linha entre dois retângulos, e a cardinalidade 基数 é marcada em cada extremidade.
- Na notação "pé de corvo", uma barra simples significa "um" e um pé de três pontas significa "muitos". Leia cada linha em ambas as direções: cada cliente faz muitos pedidos; cada pedido é feito por um cliente.
- O diagrama é desenhado antes de qualquer tabela ser criada, e os relacionamentos nele se tornam as chaves estrangeiras.
Um retângulo por entidade, uma linha por relacionamento
Uma barra para um, um pé para muitos
In an E-R diagram, the number of one entity that can relate to one of the other, marked at each end of the line, is the ____. · Em um diagrama E-R, o número de uma entidade que pode se relacionar com uma do outro, marcado em cada extremidade da linha, é a ____.
Cardinality is one or many at each end; crow's-foot notation draws a bar for one and a foot for many. · Cardinalidade é um ou muitos em cada extremidade; notação pé-de-galinha desenha uma barra para um e um pé para muitos.
The three kinds of relationship
- One-to-one (1:1): each member has one library card and each card belongs to one member. Rare; the two entities are often merged into one table.
- One-to-many 一对多 (1:M): one customer places many orders; each order belongs to one customer. Implemented by putting the "one" side's primary key into the "many" side's table as a foreign key.
- Many-to-many 多对多 (M:N): a student takes many courses and a course has many students. It cannot be implemented directly; it needs a link table.
Os três tipos de relacionamento
- Um-para-um (1:1): cada membro tem um cartão de biblioteca e cada cartão pertence a um membro. Raro; as duas entidades são frequentemente fundidas em uma única tabela.
- Um-para-muitos 一对多 (1:M): um cliente faz muitos pedidos; cada pedido pertence a um cliente. Implementado colocando a chave primária do lado "um" na tabela do lado "muitos" como uma chave estrangeira.
- Muitos-para-muitos 多对多 (M:N): um aluno cursa muitas disciplinas e uma disciplina tem muitos alunos. Não pode ser implementada diretamente; precisa de uma tabela de ligação.
Each customer can place many orders, but each order belongs to one customer. This relationship is: · Cada cliente pode fazer muitos pedidos, mas cada pedido pertence a um único cliente. Esse relacionamento é:
One customer → many orders, each order → one customer: a one-to-many relationship. · Um cliente → muitos pedidos, cada pedido → um cliente: um relacionamento um-para-muitos.
Match each relationship to its cardinality. · Associe cada relacionamento à sua cardinalidade.
1:1 each side has one; 1:M one side has many; M:N both sides have many (needs a link table). · 1:1 cada lado tem um; 1:M um lado tem muitos; M:N ambos lados têm muitos (precisa de tabela de ligação).
Worked example: draw the E-R diagram
- A school has teachers, classes and students. Each teacher teaches many classes; each class is taught by one teacher. Each class has many students; each student is in one class. Students may join many clubs and each club has many students.
- Four rectangles:
TEACHER,CLASS,STUDENT,CLUB.TEACHER—CLASSis one-to-many, the foot atCLASS.CLASS—STUDENTis one-to-many, the foot atSTUDENT.STUDENT—CLUBis many-to-many, a foot at both ends. - The marks: every entity present, every relationship drawn, and the correct cardinality symbol at each end. A line with no symbols is half an answer.
Exemplo resolvido: desenhar o diagrama E-R
- Uma escola tem professores, turmas e alunos. Cada professor leciona muitas turmas; cada turma é lecionada por um professor. Cada turma tem muitos alunos; cada aluno está em uma turma. Alunos podem entrar em muitos clubes e cada clube tem muitos alunos.
- Quatro retângulos:
TEACHER,CLASS,STUDENT,CLUB.TEACHER—CLASSé um-para-muitos, o pé emCLASS.CLASS—STUDENTé um-para-muitos, o pé emSTUDENT.STUDENT—CLUBé muitos-para-muitos, um pé em ambas as extremidades. - As marcações: todas as entidades presentes, todos os relacionamentos desenhados e o símbolo de cardinalidade correto em cada extremidade. Uma linha sem símbolos é apenas metade da resposta.
Link tables
- A many-to-many relationship is broken into two one-to-many relationships through a link table 连接表 that holds the two foreign keys.
ENROLMENT(StudentID, CourseID, EnrolmentDate): one student has many enrolments, one course has many enrolments, and each row is one student on one course. Its primary key is the composite of the two foreign keys.- Data about the pairing itself, the date, a grade, goes in the link table; data about the student or the course stays in its own table.
One many-to-many becomes two one-to-many
Tabelas de ligação
- Um relacionamento muitos-para-muitos é dividido em dois um-para-muitos através de uma tabela de ligação 连接表 que contém as duas chaves estrangeiras.
ENROLMENT(StudentID, CourseID, EnrolmentDate): um aluno tem muitas matrículas, um curso tem muitas matrículas, e cada linha representa um aluno em um curso. Sua chave primária é o composto das duas chaves estrangeiras.- Dados sobre o próprio pareamento, a data, uma nota, vão na tabela de ligação; dados sobre o aluno ou o curso permanecem em sua própria tabela.
Um muitos-para-muitos torna-se dois um-para-muitos
How is a many-to-many relationship implemented in a relational database? · Como um relacionamento muitos-para-muitos é implementado em um banco de dados relacional?
A link (junction) table holds a foreign key to each side, turning M:N into two 1:M relationships. · Uma tabela de ligação (junction) armazena uma chave estrangeira para cada lado, transformando M:N em dois relacionamentos 1:M.
ENROLMENT(StudentID, CourseID, EnrolmentDate) is a link table. Which statements are true? Select all · todos that apply. · ENROLMENT(StudentID, CourseID, EnrolmentDate) é uma tabela de ligação. Quais afirmações são verdadeiras? Selecione todas as opções aplicáveis.
The link table holds the pairing and facts about the pairing. The student's own data stays in STUDENT, or it would repeat on every enrolment. · A tabela de ligação armazena o par e fatos sobre ele. Os próprios dados do aluno permanecem em STUDENT, caso contrário, repetiriam-se em cada matrícula.
Normalisation
- Normalisation organises the tables so that each fact is stored exactly once, cutting redundancy and inconsistency. It passes through the normal forms 范式 in order: first, second, third.
- The procedure: find the entities and their attributes; choose a primary key for each; remove repeating groups and non-atomic values (1NF); remove attributes that depend on only part of a composite key (2NF); remove attributes that depend on another non-key attribute (3NF); add foreign keys for the relationships.
- The cost is more tables and more joins. The exam asks for 3NF.
Normalização
- A normalização organiza as tabelas para que cada fato seja armazenado exatamente uma vez, reduzindo redundância e inconsistência. Ela passa pelas formas normais 范式 na ordem: primeira, segunda, terceira.
- O procedimento: encontrar as entidades e seus atributos; escolher uma chave primária para cada; remover grupos repetitivos e valores não atômicos (1NF); remover atributos que dependem apenas de parte de uma chave composta (2NF); remover atributos que dependem de outro atributo não-chave (3NF); adicionar chaves estrangeiras para os relacionamentos.
- O custo é mais tabelas e mais junções. O exame pede 3NF.
Database service lab · Laboratório de serviço de banco de dados
Watch how a DBMS turns a query into safe shared data access. · Assista como um DBMS transforma uma consulta em acesso seguro e compartilhado aos dados.
Put the normal forms in the order you apply them. · Coloque as formas normais na ordem em que são aplicadas.
You reach 3NF by passing through 1NF then 2NF — each builds on the previous. · Você alcança a 3FN passando pela 1FN e depois 2FN — cada uma constrói sobre a anterior.
The main aim of normalisation is to: · O principal objetivo da normalização é:
Normalising to 3NF stores each fact once, removing update/insert/delete anomalies (at the cost of more joins). · Normalizar até a 3FN armazena cada fato uma única vez, removendo anomalias de atualização/inserção/exclusão (à custa de mais joins).
First normal form
- A table is in 1NF when every field holds a single, atomic 原子 value, there are no repeating groups, and there is a primary key.
STUDENT(StudentID, Name, Phone)withPhoneholding0123, 0456is not atomic.STUDENT(StudentID, Name, Course1, Course2, Course3)has a repeating group.- Fix both by moving the repeated data to its own table with a row per value:
STUDENT_PHONE(StudentID, Phone),ENROLMENT(StudentID, CourseID).
Primeira forma normal
- Uma tabela está em 1FN quando cada campo contém um valor único e atômico 原子, não há grupos repetitivos e existe uma chave primária.
STUDENT(StudentID, Name, Phone)comPhonecontendo0123, 0456não é atômico.STUDENT(StudentID, Name, Course1, Course2, Course3)tem um grupo repetitivo.- Corrigir ambos movendo os dados repetidos para sua própria tabela com uma linha por valor:
STUDENT_PHONE(StudentID, Phone),ENROLMENT(StudentID, CourseID).
A Phone field holds "0123, 0456" for one student. Which normal form does the table fail? · Um campo Phone contém "0123, 0456" para um aluno. A qual forma normal a tabela falha?
Two values in one cell is the 1NF failure. Move the numbers to STUDENT_PHONE(StudentID, Phone), one per row. · Dois valores em uma célula é a falha da 1FN. Mova os números para STUDENT_PHONE(StudentID, Phone), um por linha.
Worked example: second normal form
ORDER(OrderID, CustomerID, CustomerName, ProductID, Quantity)has the composite primary key(OrderID, ProductID). Is it in 2NF?- Test each non-key field against the whole key.
Quantitydepends on bothOrderIDandProductID: which order, which product. Fine. CustomerIDandCustomerNamedepend onOrderIDalone, only part of the key: a partial dependency, so the table is not in 2NF. Split it:ORDER(OrderID, CustomerID, CustomerName)andORDER_LINE(OrderID, ProductID, Quantity).
Exemplo resolvido: segunda forma normal
ORDER(OrderID, CustomerID, CustomerName, ProductID, Quantity)tem a chave primária composta(OrderID, ProductID). Ela está em 2FN?- Teste cada campo não-chave contra a chave inteira.
Quantitydepende de ambosOrderIDeProductID: qual pedido, qual produto. OK. CustomerIDeCustomerNamedependem apenas deOrderID, apenas parte da chave: uma dependência parcial, então a tabela não está em 2FN. Divida-a:ORDER(OrderID, CustomerID, CustomerName)eORDER_LINE(OrderID, ProductID, Quantity).
Worked example: third normal form
- Is
ORDER(OrderID, CustomerID, CustomerName)in 3NF? - A table is in 3NF when it is in 2NF and every non-key field depends only on the primary key, not on another non-key field.
CustomerNamedepends onCustomerID, which is not the key: a transitive dependency 传递依赖, so the table is not in 3NF. - Split again:
ORDER(OrderID, CustomerID)andCUSTOMER(CustomerID, CustomerName), withCustomerIDa foreign key. The name is now stored once, however many orders the customer places.
Each form removes one kind of dependency
Exemplo resolvido: terceira forma normal
- Está
ORDER(OrderID, CustomerID, CustomerName)em 3FN? - Uma tabela está em 3FN quando está em 2FN e todo campo não-chave depende apenas da chave primária, não de outro campo não-chave.
CustomerNamedepende deCustomerID, que não é a chave: uma dependência transitiva 传递依赖, então a tabela não está em 3FN. - Divida novamente:
ORDER(OrderID, CustomerID)eCUSTOMER(CustomerID, CustomerName), comCustomerIDsendo uma chave estrangeira. O nome agora é armazenado uma única vez, independentemente de quantos pedidos o cliente faça.
Cada forma remove um tipo de dependência
Normalising to 3NF stores each fact once and removes update anomalies, at the cost of more tables and joins. · Normalizar até a 3FN armazena cada fato uma única vez e remove anomalias de atualização, à custa de mais tabelas e joins.
That trade-off — cleaner data versus more joins — is why 3NF is the usual target. · Esse trade-off — dados mais limpos versus mais joins — é por que a 3FN é o alvo usual.
Saying why a table is, or is not, in 3NF
- Not in 3NF: name the dependency. "
TEACHERis not in 3NF because the non-key attributeDepartmentNamedepends on the non-key attributeDepartmentID, not on the primary key." - In 3NF: cover all three conditions. "Every attribute is atomic with no repeating groups; there is no partial dependency on part of the key; every non-key attribute depends only on the primary key, with no transitive dependency."
- Then, if asked, give the normalised tables in the standard notation with the foreign keys marked.
Dizer por que uma tabela está, ou não, em 3FN
- Não em 3FN: nomeie a dependência. "
TEACHERnão está em 3FN porque o atributo não-chaveDepartmentNamedepende do atributo não-chaveDepartmentID, não da chave primária." - Em 3FN: cubra as três condições. "Todo atributo é atômico sem grupos repetitivos; não há dependência parcial sobre parte da chave; todo atributo não-chave depende apenas da chave primária, sem dependência transitiva."
- Depois, se solicitado, forneça as tabelas normalizadas na notação padrão com as chaves estrangeiras marcadas.
In TEACHER(TeacherID, Name, DepartmentID, DepartmentName), why is the table not in 3NF? · Em TEACHER(TeacherID, Name, DepartmentID, DepartmentName), por que a tabela não está na 3FN?
A transitive dependency. Split out DEPARTMENT(DepartmentID, DepartmentName) and keep DepartmentID in TEACHER as a foreign key. · Uma dependência transitiva. Separe DEPARTMENT(DepartmentID, DepartmentName) e mantenha DepartmentID em TEACHER como chave estrangeira.
Marks that slip away
- 2NF is only a question when the primary key is composite. A single-field key cannot have a partial dependency.
- 3NF requires 2NF. Say both when justifying.
- Atomic means one value per cell. "Two phone numbers in one field" is a 1NF failure, not a 3NF one.
- Naming the normal form is not the answer; naming the dependency is. More tables after normalising is the point, not a fault.
Marcas que escapam
- 2FN é apenas uma questão quando a chave primária é composta. Uma chave de campo único não pode ter dependência parcial.
- 3FN exige 2FN. Cite ambas ao justificar.
- Atômico significa um valor por célula. "Dois números de telefone em um campo" é uma falha de 1FN, não de 3FN.
- Nomear a forma normal não é a resposta; nomear a dependência é. Mais tabelas após normalizar é o objetivo, não um defeito.
You've got it
- an E-R diagram shows entities as rectangles and relationships as lines with the cardinality at each end: 1:1, 1:M, M:N
- a many-to-many relationship is stored through a link table of the two foreign keys, its primary key their composite
- 1NF atomic values, no repeating groups, a primary key · 2NF no partial dependency on part of a composite key · 3NF no transitive dependency between non-key attributes
- justify by naming the dependency, then give the split tables with their foreign keys
Entendeu?
- um diagrama E-R mostra entidades como retângulos e relacionamentos como linhas com a cardinalidade em cada extremidade: 1:1, 1:M, M:N
- um relacionamento muitos-para-muitos é armazenado através de uma tabela de ligação das duas chaves estrangeiras, cuja chave primária é o composto delas
- 1FN valores atômicos, sem grupos repetitivos, uma chave primária · 2FN sem dependência parcial sobre parte de uma chave composta · 3FN sem dependência transitiva entre atributos não-chave
- justifique nomeando a dependência, depois forneça as tabelas divididas com suas chaves estrangeiras