I have three tables: user, friend and family.
User is entity.
Friend is relationship.
Family is relationship.
However, if I would like to set privacy level which can control who can view my full information. i.e. Only friend can see my hobbies, and only family can see my current location.
I don't know how I can implement this on ER design.
Option 1:
User{
attribute 1: ID;
[other attributes]
}
Friend{
Attribute 1: FriendID;
}
Family{
Attribute 1: family ID;
}
How can I meet the requirements? Still confused about it. Anyone has a rational solution ?
ER diagrams are really a seperate issue from security. ER diagrams just state what exists and how it is realated.
The best place for this kind of secuiry is in the model. When you someone asks for your current location, check if they are your family, etc...
This is especially true since current location is likely to be calculated from GPS, not stored as an entity in the database. If it is, you could potentially include a forign key from current location to familyID that would tie these together.
If this doesn't make sense, please provide more details on hobbies and current location.
Related
I'm sorry if this is the wrong place for this question. I volunteer for a charity group that has to store sensitive data, as we are a new type of format, there are no systems that fit within our needs or our budget. Someone else started building the database, I wasn't sure he was resolving the relationships correctly, so I presented him with an alternate ER model and now we haven't heard back from him, so I am left to build it by myself.
As we have to store sensitive data, I'm reluctant to put my database design on here in it's entirety, so if there is a way I can privately discuss this with someone, that would be my preference, as I would love to get someone else to check it in full to make sure it's ALL good... but for now, can someone confirm if I have resolved the relationships correctly, or if the original design was better?
The database description is: There are different types of members -
Client, Staff, Professional (Offsite), Supplier, Family, General. There are different types of Staff members: Managers, Volunteer, Professional (Onsite), Admin, Committee, Lecturer. A member can be one or many types eg: Client/Volunteer/Family, Supplier/Volunteer, Manager/Lecturer/Volunteer/Committee/Family.
The original guy resolved this by creating a separate table for each user, each table storing a name and address eg:
Client - ClientName, ClientAddress
Professional - ProfessionalName, ProfessionalAddress
Employee - EmployeeName, EmployeeAddress
Family - FamilyName, FamilyAddress
My only problem with this is that I would ideally like one person to have one MemberID with their name and address, but with the original design each person would have a different ID for each type of person that they were, all storing name, address, phone number, email etc.
I thought that creating a Member table and having a Member Type table with a joining Member Type List table would be a better design. This is how I have resolved the issue:
Member Tables
Have I done this correctly or should I continue with the original design?
Thanks
Update:
Staff Model
It makes sense to store all member related data within one table.
Also for programming, I cannot imagine any use case that would support having different tables for each member type.
That being said, I advise you to look up the concept of "user roles", since this seems very similar.
You have different users (members) and they can have different roles (member type). Based on your roles you might want to show different data / allow different actions / send specific mails (or whatever else you can imagine).
So generally your approach looks good. The only thing I think about is that right now you don't have stored who is a "Staff" member for example. If you just have one list with different names you don't store the structure.
Depending on your use cases you can e.g. make another column in MemberType table "isStaff". Or, if you need to be more flexible and there are likely more different member types in the future, you can make another table (e.g.) MemberTypeParent and set a foreign key on your MemberType table to that table to make the connection.
It all depends on what you want to do with the data in the future.
So I have some question about the association, aggregation and composition in UML diagram. Here is some scenarios :
Product review rating composition to product review. This means that for each product review rating MUST HAVE product review? If product review doesn't exist, rating for review doesn't make sense.
Customer NRIC associate to cart and order. We cannot use aggregation because if customer does not exist, cart and order cannot exist also.
Can somebody please help me check if my relationships are correct? Is it good to link all your tables with association because I kind of confused on aggregation and association. I do not know when to use that.
Correct me if I am wrong. Thanks in advance.
Take a look at this class diagram example for composition:
Composition declares an ownership associationship. Person owns Leg and Hand. Or other way around, Hand belongs to Person.
Now ask yourself how would you describe each relationship in your model. If you would say Product review rate owns a Product review or Product review belongs to a Product review rate, then your diagram is OK. If the ownership has the opposite direction (Product review rate belongs to Product review, then the diamond must go to the other side of the association.
The same thing applies to aggregation. If the association somehow declares an ownership, then the diamond must go to the side of the owner class.
The difference between aggregation and composition is that objects owned as composites can't be created without their owner, so usually they are created by their owner. These objects are destroyed when their owner is destroyed, they couldn't be used by another owner after their owner dies. Objects owned by an aggregation association can be created without their owner and possibly could outlive him and serve another owner.
"Introduction to Database Management Systems" by Raghu Ramakrishnan and Johannes Gehrke contains following ER diagram:
For example, we might identify a subset of employees as Senior Emps.
We can modify Figure 2.12 to reflect this change by adding a second ISA node as a child of Employees and making Senior Emps a child of this node.
Why do we need another ISA node? Why don't we just add this new entity to the current ISA node? Does that matter?
"Can't we use the existing ISA node to create this relationship?"
(Disclaimer : read all of this a bit tongue-in-cheek. ER was never really intended to be logically complete and precise in its expressive power, and moreover there are so many different ER dialects that it's hard to be absolutely certain of what some given dialect seeks to express, and how, and what it does not seek to express)
What you would lose is the characteristic of exclusiveness between the various IS_A "sub-entities". Your example design as given is presumably intended to explicitly document the notion that an employee can never be both hourly_emp and contract_emp.
If an employee can be both "senior" and "contract", there is no exclusiveness between them, and if the ER dialect's IS_A triangle intend to express exactly such exclusiveness, then your solution would be wrong.
But (to repeat) note that none of this is actually cast in stone. All depends on what the intended semantics are of the symbols used in your particular ER dialect.
In my opinion, the current ISA node (that is in the diagram above) determines how employees are paid, so simply add another one onto the current node doesn't make a whole lot of sense because SeniorEmployees can be either hourly or contract.
Does that make sense?
The reason you would create any entities with an ISA relationship is to give the new entity additional attributes.
Just like in object-oriented modeling, you would create a new subclass so that the new class can have additional data or additional methods relative to its superclass.
So the implication of that example is that SeniorEmployees should have some new column(s), for instance to store an award for years of service or something.
If there are no new attributes that are unique to SeniorEmployees, I'd just treat them the same as regular Employees, no need to create a new child table.
Two advantages of ISA:
descriptive attribute specific to sub-class.
identity entities that participate in a relationship.
Simply read ISA as "is a". Hourly employees ---> is a ---> employee (bottom up approach as hourly employees and contract employees are generalized by employees).
For more details refer to "Generalization, Specialization and Aggregation in ER Model".
Here is the scenario.
Two completely different Entities are independently related to the third entity in the same way. How do we represent it in the ERD? or (Enhanced ER)
Ex:
Student "BORROWS" BOOK (from the library)
DEPARTMENT "BORROWS" BOOK (from the same library).
If I define 'BORROWS' relationship twice, it would be awkward and clumsy in terms of appearance in the diagram, and increase the complexity of implementation as well.
At the same time, I can not declare a ternary relationship since STUDENT and DEPARTMENT are not inter-related in a relationship-instance.
However, I couldn't find a better way.
How do I solve it?
If Wikipedia is to be believed, Enhanced ER permits inheritance. Why don't you have a BORROWER entity (with the appropriate relationship), and have STUDENT and DEPARTMENT subclass that?
I've been having a similar issue - where a company or a person can order a product.
You've got an order, that can belong to either a person, or a company - so what do you link the relationship to? I'm thinking orders will have a companyId, and a personId foreign key, but how do you make them exclusive? The data returned won't necessarily be the same - a company doesn't have a first name / last name field for example.
I guess it could be done by having a name returned, and in the case of a person build the string out of firstname / lastname, and in the case of a company use the companyname field .
There are couples of questions around asking for difference / explanation on identifying and non-identifying relationship in relationship database.
My question is, can you think of a simpler term for these jargons? I understand that technical terms have to be specific and unambiguous though. But having an 'alternative name' might help students relate more easily to the concept behind.
We actually want to use a more layman term in our own database modeling tool, so that first-time users without much computer science background could learn faster.
cheers!
I often see child table or dependent table used as a lay term. You could use either of those terms for a table with an identifying relationship
Then say a referencing table is a table with a non-identifying relationship.
For example, PhoneNumbers is a child of Users, because a phone number has an identifying relationship with its user (i.e. the primary key of PhoneNumbers includes a foreign key to the primary key of Users).
Whereas the Users table has a state column that is a foreign key to the States table, making it a non-identifying relationship. So you could say Users references States, but is not a child of it per se.
I think belongs to would be a good name for the identifying relationship.
A "weak entity type" does not have its own key, just a "partial key", so each entity instance of this weak entity type has to belong to some other entity instance so it can be identified, and this is an "identifying relationship". For example, a landlord could have a database with apartments and rooms. A room can be called kitchen or bathroom, and while that name is unique within an apartment, there will be many rooms in the database with the name kitchen, so it is just a partial key. To uniquely identify a room in the database, you need to say that it is the kitchen in this particular apartment. In other words, the rooms belong to apartments.
I'm going to recommend the term "weak entity" from ER modeling.
Some modelers conceptualize the subject matter as being made up of entities and relationships among entities. This gives rise to Entity-Relationship Modeling (ER Modeling). An attribute can be tied to an entity or a relationship, and values stored in the database are instances of attributes.
If you do ER modeling, there is a kind of entity called a "weak entity". Part of the identity of a weak entity is the identity of a stronger entity, to which the weak one belongs.
An example might be an order in an order processing system. Orders are made up of line items, and each line item contains a product-id, a unit-price, and a quantity. But line items don't have an identifying number across all orders. Instead, a line item is identified by {item number, order number}. In other words, a line item can't exist unless it's part of exactly one order. Item number 1 is the first item in whatever order it belongs to, but you need both numbers to identify an item.
It's easy to turn an ER model into a relational model. It's also easy for people who are experts in the data but know nothing about databases to get used to an ER model of the data they understand.
There are other modelers who argue vehemently against the need for ER modeling. I'm not one of them.
Nothing, absolutely nothing in the kind of modeling where one encounters things such as "relationships" (ER, I presume) is "technical", "precise" or "unambiguous". Nor can it be.
A) ER modeling is always and by necessity informal, because it can never be sufficient to capture/express the entire definition of a database.
B) There are so many different ER dialects out there that it is just impossible for all of them to use exactly the same terms with exactly the same meaning. Recently, I even discovered that some UK university that teaches ER modeling, uses the term "entity subtype" for the very same thing that I always used to name "entity supertype", and vice-versa !
One could use connection.
You have Connection between two tables, where the IDs are the same.
That type of thing.
how about
Association
Link
Correlation