I'm new to database designing.
I'm trying to figure out the difference between the following two ER designs:
Assuming each record in parent tables (State and City) participates in 1:M relationship in both the ER designs, is there any functionality difference that could arise among them? Is there any situation where I might prefer one over another?
In the first case the City determines the State (City_Id->State_Id); in the second it doesn't. That's a significant difference and what matters is which of these designs more accurately describes the reality you are intending to model.
If City_Id->State_Id is correct and if these are supposed to be relational database designs then the Locality relation described by the second diagram would violate 3rd Normal Form (first diagram looks OK).
Related
I am working on a practice questions for ERD, and I was wondering what the correct approach is for modelling either or relationships.
For example, in a Taekwondo school, you will have customer accounts, which will represent and pay for one or many students. The account is owned by either a parent, or a the student himself. Therefore the account owner is either a parent or a student. What is the best way to represent a relationship like this?
Here is what I came up with, but I am unsure if this conforms to best practice:
1 Clarification
Representing an either-or relationship in Crows foot ERD
The diagram you have is a good start. Note:
that is not ERD. That is way more detail than an ERD can handle
ERD does not have a Crows Foot, that is IEEE notation
Ultimately, you need a data model that has the detail required for an implementation (way more than ERD). That is why I said your diagram is a good start, it is moving in that direction. However, we have a Standard for Relational Data Modelling: IDEF1X, the Standard for modelling Relational databases since 1993, available since 1984 before it was elevated to a standard.
Evidently both Dr E F Codd's Relational Model, and the diagrammatic method for modelling Relational databases is suppressed.
The relationship symbol, especially the cardinality, in IEEE notation is better (more easily understood) than IDEF1X, therefore most people use that. All data modelling tools, such as ERwin, implement IDEF1X, and allow either IDEF1X or IEEE notation for relationships.
2 Request
The diagram as intended is illegal. Why ? Because you have one relationship going "out" of Person, to two tables. Not possible. You are asking how to represent such a relationship in a data model (not possible in ERD). The answer is, that is an OR Gate is logical terms, a Subtype in Relational terms.
Please inspect these answers for overview and detail. Follow the links for implementation details and code:
How can I relate a primary key field to multiple tables?
Structuring database relationships for tracking different variations of app settings
How do I get around this relational database design smell?
Subtypes can be:
Exclusive (the Basetype must be one of the Subtypes), or
Non-Exclusive (the Basetype must be any [more than one] of the Subtypes).
From Role it appears to be Exclusive. What you call Role is a Discriminator in IDEF1X.
That is best practice for Relational databases.
Relational Data Model
This is best practice for for data models (this level of detail shows attribute name only).
Of course, all my data models are rendered in IDEF1X.
My IDEF1X Introduction is essential reading for beginners.
ParentId, StudentId, OwnerId are all RoleNames (Relational term)of PersonId. This makes the context of the FK explicit.
3 Correction
but I am unsure if this conforms to best practice
Since you are concerned, there is one other issue. There is a mistake in your model, it is one of the common errors that happen when one stamps id on every file. Such a practice cripples the modelling exercise, and makes it prone to various errors. (I understand that you are taught that crippling method.)
Since a Person can have 0-or-1 Account, and the Person PK (which is unique to a Person), is a FK in Account, it can be the PK in Account.
AccountId is not necessary: it is 100% redundant, one additional field and one additional index, that can be eliminated.
When I am studying the database lecture on E/R model, it illustrates how to convert ternary relationship to binary. One way is using weak entity relationship as follows (each relationship is M:N cardinality):
ternary relationship:
convert the upper relationship with weak relationship
However, in another example:
it states in the lecture slide: "if each technician can be working on several projects and uses the same notebooks on each project, then we can decompose 3-ary relationship into binary relationships"as follows:
which I could not understand. I still kinda confused about when we should use weak entity approach and when we could just simply convert it to binary relationships as the latter one. Thanks!
Your second image illustrates a confusion between conceptual and physical data models, or a confusion between the ER and network data models. The physical implementation of the models in the first two images are the same, what differs is the interpretation of entities and relationships. The entity-relationship model supports ternary relationships, but doesn't support multiple identifying relationships for a single weak entity set. I would advise you to disregard the second image completely.
The third and fourth images illustrate a fourth normal form decomposition using ER notation. This isn't something you can do with any ternary relationship, but rather something you do when 2 or 3 independent relations have been incorrectly combined into one. For more information, I suggest you read up on Fourth Normal Form.
I'm new to data modelling and have started following tutorials to learn more.
I am trying to create a model for a hypothetical scenario and am struggling to validate what I have created to see if it is what would be considered a correct data model.
Essentially all im trying to do is correctly store data in a normalised form. In my scenario there are 3 types of people and each share some attributes and have one set of contact details each.
Does the below data model look feasible?
The relationship between person and one of defendant, magistrate, or staff-member is a case of the class/subclass pattern. There are two common ways of modeling this pattern in relational tables.
One way is called "Class Table Inheritance". You can find out more by visiting this tag: class-table-inheritance or by searching the web for Martin Fowler's treatment of the same subject. Your design resembles this design.
Another way is called "Single Table Inheritance", which you can also research the same way. single-table-inheritance. It's simpler, and works ok in some cases. You deal with fewer joins, but you deal with more NULLS.
Many people who go for class table inheritance also apply a technique called "Shared Primary Key". shared-primary-key. Using this technique, Defendant, Magistrate, and Staff_Member would each use a copy of person_id as the primary key. This primary key also functions as a foreign key. Shared primary key enforces the one-to-one nature of the IS-A relationships that exist in this case.
If you want to go further in data modeling, you might want to learn ER modeling as a distinct data model from the relational model. What you've done here is essentially to use ER diagramming to diagram a relational model. There's nothing wrong with that, but it obscures a whole new field of study, generally called conceptual data modeling.
If you generate an ER model at the conceptual level, you don't attempt to implement it in terms of tables. There is a diagramming convention in ER that goes under the name "generalization/specialization" that allows you to depict a class/subclass situation, while remaining silent on how it's going to be implemented.
Conceptual data models have an area of usefulness, in addition to relational data modeling. What makes conceptual data models useful is precisely the fact that they present the information requirements without stating how those requirements are going to be met.
Once you are proficient at creating conceptual data models, it's not hard to convert one of them to a relational model.
This may be more than you bargained for, but since you are taking on learning modeling, I thought I'd survey some of the field for you.
I'm doing a work about database, and now I need to show three different images, one image with the conceptual model, other with logical model and other with physical model of a database.
But Im here with some difficults to understand which image represents each model.
I'm looking for reliable information about this, but I find different answers and I'm a bit confused.
So I came here to see if you can help me.
I have below my three images, do you think I have the correct title for each image?
Conceptual model:
In conceptual model, I think that I neeed to put my tables with atributes but without relationships.
Logical Model:
In logical model, I think I need to put my tables with atributes, but now with my relationships.
Physical Model:
In physical model, I think I need to put my tables with atributes, but now with my relationships and also with foreign keys
A Conceptual Model (CM) is an informal representation of the business represented in a manner that is understood by users. It will consist of classes of entities with attributes and the business rules regarding these. It is often presented as Entity-Relationship Diagrams.
A Logical Model (LM) formalizes the CM into data structures and integrity constraints. it should include all the data structures and integrity constraints for the data (this is all constraints, not just that subset of constraints that are easily defined in most available database management systems). It is database management system agnostic.
The LM may be presented as a Relational Data Model (RDM). In which case all the data structures and integrity constraints will be formally represented only using mathematical relations.
A Physical Model (PM) is a representation of the LM on specific hardware and database management system. It may consist of information such as storage sizing and placement; access methods such as indexing; and distribution such as clustering or partitioning.
Using these definitions I would say that all you diagrams are versions of Conceptual Models; as they do not include all the integrity constraints for the data being managed and do not include any information regarding an implementation on specific hardware or database management system.
The conceptual/logical/physical layers have changed somewhat over the years, and also vary according to different schools of thought. The way I learned it, back in the 1980s was this:
The conceptual model summarizes the semantics of the data with reference to the subject matter. It is not bound to a relational implementation. The implementation could be in some sort of prerelational database, or even in classical files of records. You have entities, relationships, attributes, and domains. You also have business rules. That's about it. Like your summary, it's primarily for communication with users and other stakeholders. The idea is to pin down the requirements during the analysis phase.
The logical model is a preliminary design. It's bound to the relational model, but not to a specific DBMS. You have relations, tuples, attributes, and constraints. Relationships are implemented as foreign keys, sometimes requiring junction relations. I tended to use the terminology of tables, rows, and columns, instead of relations, tuples, and attributes, but that's mostly nomenclature. Normalization is relevant here.
The physical model is a detailed design. It's DBMS specific, and takes into account data volume, expected traffic, and performance. Denormalization is relevant here. This leads directly to a creation script.
This is by no means the majority view, let alone a general consensus. You need to understand your audience to see if this framewok works.
Is it a homework or what? The question seems so artificial...
The 3rd one is Physical because the data types are closer to actual DBMS data types.
Between the 1st, and 2nd ones... I'm stuck. The only difference is the crow-feet relationship. If there's a progression between the three images, I'd guess this would make the 2nd one the Conceptual.
But it is difficult because, with PowerDesigner, you could still represent the relationship with crow-feet in the Logical model. But anyway, there should be evidence of the migration of the "foreign key" attribute id_cat in the News entity, which is missing here.
Nope. I was reading my example diagrams too fast, there's no migration in Logical model.
So, just by elimination, I'd make the 1st one the Logical.
I have to create an ER diagram based on a relational schema.
There is a table of players, and a table of zones. A player can 'live' in many zones, and each zone is owned by one or more players.
I've come up with this simple ER diagram but I'm not sure having relationships going each way is allowed?
Cheers
Yes, that is a perfectly good Entity Relation Diagram. (I am not responding as to whether it makes sense or not: you still need to resolve the Relations and Cardinality.)
Using the correct terms helps people understand exactly what you are discussing, and which level you are discussing. Loose talk results in much more volume in the discussion, and time wasted in clarifying what you meant by which term. Not good for productive technical endeavours.
At this early stage, it is normal to model Entities and Relations (not Attributes), that's why it is called an ER diagram; we are nowhere near modelling the data. The Relations are relevant, and that's why you are detailing and evaluating their nature in the diamonds and Cardinality. The goal is to clarify the true Entities, and their Relations to each other. Many-to-many relations remain as relations. The ERD is purely Logical, there is no Physical.
Once you have some confidence with that, that you have gotten the Entities and Relations right, you move onto a Data Model (which includes Attributes). Still at a Logical level, the n::n relations remain as relations.
As you progress, you may show further detail, such as Domain for each Attribute. That's the DataType, but at the Logical level, just as the terms are Entity = Table and Attribute = Column, Domain = DataType.
.
When you get to the Physical level, the Data Model has Tables; Columns; DataTypes.
And n::n Relations are manifested as the Associative Tables.
.
The idea is, as long as you are working through the prescribed steps, at (1), the content in the diamonds will determine (expose) if they need to be stored, and the diamond is thus promoted to an Entity; otherwise it remains a Relation.
There is a junction table called lives-in in the relational schema I've been given. However, I thought when mapping a relational schema [back] to an ER diagram a junction table becomes a relationship?
The Relational term is Associative table.
Yes. If it is a pure n::n Table (containing nothing but the two FKs to the PKs of the parent Tables), at the ERD level, which is Logical only, it is a Relation.
If it has Columns other than the two FKs, it is an Entity.
Since there's a many-to-many relationship between [Players] and [Zones] you have to add a junction table (called for ex. [PlayersZones]). The notation itself is correct (Chen notation), though I prefer the Crow's Foot Notation.
I am not able to see your images (blocked!) so I'll just try to describe the "correct" design. If a player living in a zone doesn't necessarily mean they own it, you should have four tables:
PLAYER (playerid, <other fields>)
ZONE (zoneid, <other fields>
PLAYER_ZONE(playerid, lives_in_zoneid)
ZONE_OWNER (zoneid, owner_playerid)
Otherwise three tables would suffice.