I am trying as an exercise for an exam to transfer a database from the ER model to a relational database.
However, I am very unsure whether my solution makes sense. In particular, the two relationships between location and has makes great problems. I thought I could add one ZipCode as a regular primary key into the table has and a second ZipCode as foreign key. I would be very grateful if someone could help me with this.
My Solution so far:
If you are following Chen ER design with this Chen ER diagram then you need a table for every entity type box and every relationship (association) type diamond and a FK (foreign key) for every participation/role line for a relationship type.
(It is a bad idea to call lines/FKs "relationships" or "associations" in a Chen context because diamonds/tables represent relationship types and lines/FKs represent participations.)
So your Ship tourID would be dropped in favour of relationship/table takes with lines/FKs to Ship & Tour. And you would have two FKs in the has table to Location. It doesn't matter that you need different column names in the relationship table than in the participant table. A FK just says the values in some table & column list appear in some other table & column list. The diagram says the names are start & target; use them.
Don't use a flaccid uninformative name like has. If you picked a better name and/or explained when a triplet of entities satisfied the has relationship then we could know what reasonable designs would be. Eg you may not be using cardinalities correctly. The Chen way is, a number or range tells for some instance of the entity type how many relationship instances it can participate in. Another way is, a number or range tells you for a some combination of entity instances of the other participating entity types how many instances of the line's entity type can participate with it. If the latter has a zero that means a relationship instance can have a NULL. But that can't arise in a Chen design; participating entity instance combinations identify relationship instances and form PKs (primary keys).
However, a Chen design can't express all relational designs. And we can represent the same data as a Chen ER schema by rearranging tables. Eg dropping binary relationship tables that are not many:many and putting FKs (sometimes nullable) into entity tables instead, just as you did with takes, Ship & Tour. Some methods have non-Chen diagrams expressing such designs directly. Others allow it in the move from Chen diagram to schema. You have to ask your teachers whether they care just what variations from the Chen style of ER diagrams and corresponding schemas you are permitted to make.
(It is this dropping in non-Chen methods of explicit 1:many relationships/associations and their representation by FKs that leads to FKs being incorrectly (but commonly) called "relationships" or "associations".)
Related
I'm finding the best way to convert an eer diagram to the corresponding relational diagram. I have a generalization entity with some specializations which have separate relationships with other entities. The generalization entity has in turn a n-to-m relationsip with an entity. The following drawing clarifies the situation:
Eer diagram with specialization and n-to-m relationship.
As the two specialized entities have separate relationships, I should convert them to two separate tables. Meanwhile, I should create a table modeling the n-to-m relationship which relates the entity 'User' to the entity 'Newsletter' (or better, its specializations). How to cope with this problem? I've not found any useful information.
The only possible solution I thought to was to create two separate tables modeling the n-to-m relationship, one linked to 'User' and 'Programming newsletter' tables, one linked to 'User' and 'Travel newsletter' tables. But I'm looking for opinions for that.
I see no problem. I would implement your diagram using the following tables:
User (nickname PK, name, address)
Newsletter (name PK, supervisor, type)
Subscription (user_nickname PK/FK, newsletter_name PK/FK)
Programming_Newsletter (newsletter_name PK/FK, type FK, language)
Travel_Newsletter (newsletter_name PK/FK, type FK, means_of_transport)
I probably wouldn't use user nicknames / newsletter names as keys since I prefer stable compact identifiers, but that's another topic.
I think there are a couple of ways to go about this.
The simplest one, would be to break the assumption "As the two specialized entities have separate relationships, I should convert them to two separate tables". If you keep your specialisations together in a single table, you can use STI (Single table inheritance) for your generalisation. This approach has a drawback though, which is that your table will have many NULL values for those relationships that do not belong to the concrete specialisation.
The other approach, would be to use CTI (Class Table Inheritance). This approach assumes that there will be a specific table for each specialisation of your generalisation. This would get around the NULL problems, but it can potentially introduce a performance problem due to the fact that your code will need to eagerly join from the generalisation table to the specialisation on almost every single query you make to retrieve them.
I don't quite see the issue in the n-to-m relationship between User and Newsletter. You should be able to have a regular intermediate table that creates the association between the two, since there are no further attributes that complement that relationship.
Do table associations need to have roles. I find this difficult to understand for example if there is a product table and an inventory table and A row in the product table is associated with many rows in an inventory table.(eg. each copy of a particular product has a unique serial number which is a foreign key referencing a column in the inventory table)can be associated with one or (likely) more rows in another table
I find this kind of relationship difficult to describe. If it were inverted you could say a product is held in 1 and only 1 inventory and an inventory contains 1 to many products.
I was having trouble understanding a similar problem as described above until I found the various definitions for the relationships on this page
http://help.filemaker.com/app/answers/detail/a_id/9922/~/understanding-and-creating-many-to-many-relationships-in-filemaker-pro
Maybe I am thinking about it the wrong way
Read about Chen's ERM (Entity-Relationship Model) method/diagrams: Entities are boxes (& entity type tables), relation(ship) types are diamonds (& association tables), participations of entity types are lines from diamond to box (& FKs) and properties (non-entity "participants" or attributes) are ovals on lines. This makes it clear what is a relation(ship)/table and what is a participation/FK. Then some ER variants misuse the term "relationship" for FK and leave out diamonds so it's not so clear what the relation(ship)s and participations are. (See wikipedia Entity-relationship model.) You use the term "role", which is used in Object-Role Modeling for participation (by entity or property). It is the truest to the relational model and can be mapped to ER and ER variant methods. (ER has the problem of artificial distinctions. There is really no difference between an entity, relationship or property, and every table superkey corresponds to an "entity".)
The following is an Entity Relationship of a a Baseball League.
I'm having a bit of confusion understanding Relations and Attributes of Relations.
An description of the diagram follows:
According to the description, Participates is a Relation and Performance is an Attribute (complex) of Participates.
Questions:
How do Participates Map to actual tables in a database?
Would there be a Participates table with the fields that define Performance?
{Hitting(AtBat#, Inning#, HitType, Runs, RunsBattedIn,
StolenBases)}, {Pitching(Inning#, Hits, Runs, EarnedRuns, StrikeOuts, Walks, Outs, Balks, WildPitches)}, {Defense(Inning{FieldingRecord(Position,
PutOuts, Assists, Errors)})}
Similarly are Plays_For, Away_Team and Home_Team also tables.
As you create tables in a database (say MySql) how are Relations differentiated from Entities / Objects like Player, Team and Game.
Thanks for your help.
Question 1: Participates would be an actual table with foreign key columns for Player and Game as well as the column(s) for Performance. All M-N relationships need to be modelled in a separate table.
Question 2: To keep it as a semi-decent relational DB you would have to separate all the info into separate columns so that each column would only hold one singular data. If you didn't separate the data you would break the first normal form and would probably run into problems later in the design.
Question 3: As these three are 1-N you could also implement them with columns on the N-side. In the Game table for example you could have two foreign keys to Team table as well as all the data about the relationships in columns. For claritys sake you could make those relationships as separate tables also. As a sidenote: are you sure Player-Team is a 1-N-relationship so that a if a player changes teams the history-info about the StartDate and EndDate of the previous team is immediately lost?
Question 4: They are all treated absolutely the same - no differentiation.
I am trying to lay out the concept for a Relational DB and I ran into some conceptual Problems:
If I have multiple discrete Entities that are "nested" in each other/have a hierarchy e.g.:
Bosses can have multiple Employees. These employees have different Projects they do and One Project has again multiple sections.
So
B1-Bn:
E1-En
P1-Pn
Section1 -SectionN
How would that be best mapped in a database?
Or in other words, how is this hierarchy best mapped in a relational db?
Now I have Costumers that interact with these Employees.
They are met by the bosses
Then they decide which employee will work for them.
Then they are assigned Projects, with one or more sections.
How would that be best mapped.
the Relations 1-n, m-n, 1-1: Can they be used for e.g.:
This is a Foreignkey because of the 1-n relationship.
This is a ManytoManyField because of the m-n relationship.
And is there a excellent online tool to better understand/visualize that.
Thanks so much for your time!
You may want to follow a course on relational database design; this subject takes more than a few days to explain or master. But you are on the right track.
The first thing you may be seeing is a hierarchy, but before you know it there will be relationships that aren't hierarchical, so a network is formed.
This is why relational databases do not work with hierarchies.
You identify different types of entities and have one table for each type.
For each entity type you identify the properties of such entities - each property will be a column of the table.
If a property does not have an atomic value, but a structured value, these structured values must be regarded as an entity, and must be given its own table, and the property will be a foreign key referring that table.
In this way, you will form a network of tables linked by foreign keys. This is called an entity-relationship diagram. Many designers advocate creating such a diagram first, without mapping the entity types to tables directly. They allow many-to-many relationships between entity types in the diagram. A foreign key between tables on the other hand is always many-to-1 or 1-to-1. So these designers have an "implementation" step in which they introduce an additional table for each many-to-many relationship. Personally I don't use many-to-many relationships in my diagrams to begin with.
What is normalization in MySQL and in which case and how we need to use it?
I try to attempt to explain normalization in layman terms here. First off, it is something that applies to relational database (Oracle, Access, MySQL) so it is not only for MySQL.
Normalisation is about making sure each table has the only minimal fields and to get rid of dependencies. Imagine you have an employee record, and each employee belongs to a department. If you store the department as a field along with the other data of the employee, you have a problem - what happens if a department is removed? You have to update all the department fields, and there's opportunity for error. And what if some employees does not have a department (newly assigned, perhaps?). Now there will be null values.
So the normalisation, in brief, is to avoid having fields that would be null, and making sure that the all the fields in the table only belong to one domain of data being described. For example, in the employee table, the fields could be id, name, social security number, but those three fields have nothing to do with the department. Only employee id describes which department the employee belongs to. So this implies that which department an employee is in should be in another table.
Here's a simple normalization process.
EMPLOYEE ( < employee_id >, name, social_security, department_name)
This is not normalized, as explained. A normalized form could look like
EMPLOYEE ( < employee_id >, name, social_security)
Here, the Employee table is only responsible for one set of data. So where do we store which department the employee belongs to? In another table
EMPLOYEE_DEPARTMENT ( < employee_id >, department_name )
This is not optimal. What if the department name changes? (it happens in the US government all the time). Hence it is better to do this
EMPLOYEE_DEPARTMENT ( < employee_id >, department_id )
DEPARTMENT ( < department_id >, department_name )
There are first normal form, second normal form and third normal form. But unless you are studying a DB course, I usually just go for the most normalized form I could understand.
Normalization is not for MYSql only. Its a general database concept.
Normalization is the process of
efficiently organizing data in a
database. There are two goals of the
normalization process: eliminating
redundant data (for example, storing
the same data in more than one table)
and ensuring data dependencies make
sense (only storing related data in a
table). Both of these are worthy goals
as they reduce the amount of space a
database consumes and ensure that data
is logically stored.
Normal forms in SQL are given below.
First Normal form (1NF): A relation is
said to be in 1NF if it has only
single valued attributes, neither
repeating nor arrays are permitted.
Second Normal Form (2NF): A relation
is said to be in 2NF if it is in 1NF
and every non key attribute is fully
functional dependent on the primary
key.
Third Normal Form (3NF): We say that a
relation is in 3NF if it is in 2NF and
has no transitive dependencies.
Boyce-Codd Normal Form (BCNF): A
relation is said to be in BCNF if and
only if every determinant in the
relation is a candidate key.
Fourth Normal Form (4NF): A relation
is said to be in 4NF if it is in BCNF
and contains no multivalued dependency.
Fifth Normal Form (5NF): A relation is
said to be in 5NF if and only if every
join dependency in relation is implied
by the candidate keys of relation.
Domain-Key Normal Form (DKNF): We say
that a relation is in DKNF if it is
free of all modification anomalies.
Insertion, Deletion, and update
anomalies come under modification
anomalies
Seel also
Database Normalization Basics
It's a technique for ensuring that your data remains consistent, by eliminating duplication. So a database in which the same information is stored in more than one table is not normalized.
See the Wikipedia article on Database normalization.
(It's a general technique for relational databases, not specific to MySQL.)
While creating a database schema for your application, you need to make sure that you avoid any information being stored in more than one column across different tables.
As every table in your DB, identifies a significant entity in your application, a unique identifier is a must-have columns for them.
Now, while deciding the storage schema, various kinds of relationships are being identified between these entities (tables), viz-a-viz, one-to-one, one-to-many, many-to-many.
For a one-to-one relationship (eg. A
Student has a unique rank in the
class), same table could be used to
store columns (from both tables).
For a one-to-many relationship (eg.
A semester can have multiple
courses), a foreign key is being
created in a parent table.
For a many-to-many relationship (eg.
A Prof. attends to many students and
vice-versa), a third table needs to
be created (with primary key from
both tables as a composite key), and
related data of the both tables will
be stored.
Once you attend to all these scenarios, your db-schema will be normalized to 4NF.
In the field of relational database
design, normalization is a systematic
way of ensuring that a database
structure is suitable for
general-purpose querying and free of
certain undesirable
characteristics—insertion, update, and
deletion anomalies—that could lead to
a loss of data integrity.[1] E.F.
Codd, the inventor of the relational
model, introduced the concept of
normalization and what we now know as
the first normal form in 1970.[2] Codd
went on to define the second and third
normal forms in 1971,[3] and Codd and
Raymond F. Boyce defined the
Boyce-Codd normal form in 1974.[4]
Higher normal forms were defined by
other theorists in subsequent years,
the most recent being the sixth normal
form introduced by Chris Date, Hugh
Darwen, and Nikos Lorentzos in
2002.[5]
Informally, a relational database
table (the computerized representation
of a relation) is often described as
"normalized" if it is in the third
normal form (3NF).[6] Most 3NF tables
are free of insertion, update, and
deletion anomalies, i.e. in most cases
3NF tables adhere to BCNF, 4NF, and
5NF (but typically not 6NF).
A standard piece of database design
guidance is that the designer should
create a fully normalized design;
selective denormalization can
subsequently be performed for
performance reasons.[7] However, some
modeling disciplines, such as the
dimensional modeling approach to data
warehouse design, explicitly recommend
non-normalized designs, i.e. designs
that in large part do not adhere to
3NF.[8]
Edit: Source: http://en.wikipedia.org/wiki/Database_normalization