I am an ICS student and I have been given two questions.
1.) List all the Functional Dependencies that hold for the database.
2.) For each relation in your relational schema write down whether the relation is in BCNF or 3NF and if not give a violating FD.
I'm just having problems understanding the relationship between functional dependencies and the ER Diagram. I've watched a few videos online but I'm still getting stuck on how to answer the two above questions and would appreciate some help in finding the right direction.
Below is an ER diagram and I was hoping someone could give some examples on how to start from here.
For each entity set (e.g. Department), each attribute is an FD (e.g. Department Name -> Location).
For each relationship set (e.g. Offers), there's an FD from the combination of keys of "many" entities to each of the keys of "one" entities (e.g. Course_ID -> Department Name)
Related
I was going through this site to understand ER to relational model mapping.
Below is the link:
ER Model to Relational model
Consider case 1: It says that since the passport entity type is in total participation, we can merge person and passport tables along with the has relationship into one table with all the attributes of the above three and primary key as Person_id.
My doubt is that wont it lead to a lot of NULL values for those people who do not own a passport. I was thinking that a better solution would be to include Person_id as a foreign key in the Passport relation and a separate relation for Person entity type itself.
Both the solutions seems to have their pros and cons:
1) One big table means a possibility of lot of NULL values but ease of access of passport details of a person.
2) Two separate tables mean that no NULL values but to find the passport details of people, we have to perform a join operation or search through two separate tables.
Which of these two solutions is correct? By correct, I mean to ask that in common practice in such cases, which solution is used?
Both solutions are commonly used. I would only consider option 1 if no other information depended on the passport number, but in this case I'd model it as an (optional) attribute in ER and not a separate entity. If a passport has any dependent attributes, such as country of origin or expiry date, I would model it as a separate entity and implement it using option 2.
I need to create an ER diagram and a relational model for a hospital. I have kept it simple to 3 entities. Please can someone have a look and tell me if I have normalised this correctly?
I am not sure it there should be a : relationship between the trust and patients? Does a person assume that the first entity is a single unit, in this case a hospital has x relationships to....
Diagram 2:
ER Diagram & Relational Schema
Your normalization isn't correct. First of all, you don't list functional dependencies. Without that, any attempt to normalize is just guesswork.
Now, I can make a reasonable guess, but even with that you have some problems. The Hires and Cares for relations aren't reflected in your 1NF/2NF/3NF tables. In your 2NF, you introduce a Shift relation that was presumably derived from Doctor in 1NF, but Patient_ID wasn't present in the latter, unless that's actually what the Shift column was for, but renaming fields isn't part of normalization. Also, what happened to Hospital in 2NF? It reappears in 3NF but with a Location attribute that was derived from where? Also, you're not indicating a primary key for Shift, is it correct to assume the combination of all 4 fields constitute a candidate key? It's good practice to be explicit about your keys.
Can an entity be without attributes?
Your Hospital relation does have an attribute - Hospital_ID, which represents an identity relation. Remember an attribute is a binary relation, and Hospital_ID -> Hospital_ID qualifies.
I am not sure it there should be a : relationship between the trust and patients?
What is the trust? It isn't indicated in your diagram at all.
Does a person assume that the first entity is a single unit, in this case a hospital has x relationships to....
Many-to-many relationships are decomposed into two or more one-to-many relationships, and in reading the cardinality indicators we tend to put the singular entity first, but this isn't a rule or a safe assumption. Be explicit about cardinalities.
all the attributes include in ER diagram or not?
My database have 8 tables and nearly 50 attributes, i include these 50 attributes in a single diagram OR not?
First thing - ER diagram is something that is first created usually and then later on converted into a data model like relational. So the data storing requirements are modeled into an ER diagram first and later on are converted into tables. There is rarely a case where you have to reverse engineer an existing data model into the ER diagram level (Conceptual Level).
During this process, tables are created for enitities and relationships accordingly (using some algorithmic process).
And a good way of practice is to draw the ER diagram with only entities and relationships without the attributes as it makes it very clumsy and difficult to concentrate on the actual entities and the relationships between them. Later on in a separate document or a page, you can list all the attributes corresponding to entities individually.
Hope this gives you a basic idea.
What is the difference between ER Diagrams and Database Schema? MySQL Workbench has facility to draw ER diagrams, but the symbols for ER diagrams different in other drawing tools than MySQL Workbench method.
A database schema is usually a relational model/diagram. it shows the link between tables: primary keys and foreign keys.
In database diagram the relation between an apple and a apple tree would be:
A foreign key "ID__TRE" which cannot be null in the table "APPLE" is linked to a primary key "ID_TRE" in the table "TREE".
An entity relationship diagram. Shows links between the entities and the kind of relation between them. We are not talking about tables or keys there! Usually the entity relationship diagram follows Merise model. Database manager and developer as myself usually build an entity relationship model before conceiving the relational model/diagram.
The set of symbol in Merise are:(0-1, 0-n, 1-1, 1-n). The first number 0 or 1 describes whether the other part of the association is required for an object to exist. If it is zero, it means it can exists without being associated. If it is One it means that the object only exist in relation with an other object (e.g an apple need a tree to exist --> 1, a tree needn't apple to exists -->0)
The second character tell us how many objects are accepted in the other part of the association. If it is 1, then only one object can exists in the relation, if it is n, a infinite number of object can be linked (e.g.: an apple can have one tree --> 1, a tree can have multiples apples --> n)
With Entity relationship the relationship will be described as :
An apple has to belong to at least one tree to exists and can belong to only one tree(1-1). A tree needn't an apple to exist but it can have an infinite number of apples (0-n).
In fact both description mean the same but one is database oriented while the other is modelling oriented. Some modelling software such as DB-MAIN convert automatically an ER diagram to the relational diagram.
ENTITY RELATIONSHIP DIAGRAMS (ERDs) are just that: DIAGRAMS which describe the RELATIONSHIPS between ENTITIES. Now let's look closer...
ERDs are often created by Business Analysts (NOT DBAs);
ERDs are often described in LAYMAN's terms (NOT techno-speak of DBAs or other);
ERDs are meant to summarize & clarify understanding for End Users and Business SMEs (again, NOT the DBAs or Developers)
ERDs work best when each entity is described in the SINGULAR, and the lines connecting various entities to other entities in the ERD use verbs (of action or possession, or existence) to describe each relation;
ERDs can (and do) include lines which denote n:n relationships, but this is not a requirement.
Examples of entities in an ERD for a blog: Member, Post, Comment, Category
Examples of relationships described in an ERD:
Member "posts" 1 to n Posts; (note we AREN'T describe WHAT a post looks like)
Post "relevant-to" 1 to n Categories
etc.
DATA SCHEMAS bear some resemblance to ERDs, but they should NOT be considered either equivalent or interchangeable. If you make an ERD which can be used as a data schema... be open to the possibility you DIDN'T make an ERD ! ;-)
DATA schemas are diagrams used to describe to a DBA how data will be stored in a database (relational or non-relational).
Data Schemas almost invariable describe the structure & characteristics of TABLES;
Tables are "containers" (cardboard boxes);
As such tables in a data schema are BEST named in the PLURAL
Examples of the TABLES in a SCHEMA for the same blog:
MEMBERS, POSTS, CATEGORIES, COMMENTS (relational database)
or
POSTS (keyed by Member-Date and all other columns in 1 table (non-relational database like for a "big data" project);
a data schema would then describe the data contained in each table:
MEMBER
FirstName (char:25)
LastName (char:25)
etc.
the lines between tables in a data schema would NOT try to represent any 'relation' other than a "KEY" between 2 fields which could be used to "join" the tables, and some additional characteristics of those lines to denote n:n relationships.
BOTH diagrams serve quite DIFFERENT purposes:
ERD: to make mere mortal end-users (and business owners) UNDERSTAND the model of a given business solution; and
DATA SCHEMA: a "blueprint" used by DBAs to BUILD databases, and by DEVELOPERS to CONSUME the data in that database.
A database schema is a description of the actual construction of the database. It is an all-encompassing term that refers to the collective of tables, columns, triggers, relationships, key constraints, functions and procedures. It can refer to a document that describes all of this (such as an XML Schema) or as an abstraction of database makeup itself ("It would be difficult to change the schema of the database at this point"). It does not refer to rows inserted into the schema, or data itself. You would insert data into an existing schema.
An Entity Relationship Diagram is a visualization of the relationships between tables in a database. At the very least, it includes table names visualized as squares connected by lines that represent primary and foreign key constraints. It often includes the column names and symbols that include information about what kind of relationship exists between the columns (one-to-one, one-to-many, many-to-many).
I'm using MS SQL Server 2008R2, but I believe this is database agnostic.
I'm redesigning some of my sql structure, and I'm looking for the best way to set up 1 to many relationships.
I have 3 tables, Companies, Suppliers and Utilities, any of these can have a 1 to many relationship with another table called VanInfo.
A van info record can either belong to a company, supplier or utility.
I originally had a company_id in the VanInfo table that pointed to the company table, but then when I added suppliers, they needed vaninfo records as well, so I added another column in VanInfo for supplier_id, and set a constraint that either supplier_id or company_id was set and the other was null.
Now I've added Utilities, and now they need access to the VanInfo table, and I'm realizing that this is not the optimum structure.
What would be the proper way of setting up these relationships? Or should I just continue adding foreign keys to the VanInfo table? or set up some sort of cross reference table.
The application isn't technically live yet, but I want to make sure that this is set up using the best possible practices.
UPDATE:
Thank you for all the quick responses.
I've read all the suggestions, checked out all the links. My main criteria is something that would be easy to modify and maintain as clients requirements always tend to change without a lot of notice. After studying, research and planning, I'm thinking it is best to go with a cross reference table of sorts named Organizations, and 1 to 1 relationships between Companies/Utilities/Suppliers and the Organizations table, allowing a clean relationship to the Vaninfo table. This is going to be easy to maintain and still properly model my business objects.
With your example I would always go for 'some sort of cross reference table' - adding columns to the VanInfo table smells.
Ultimately you'll have more joins in your SP's but I think the overhead is worth it.
When you design a database you should not think about where the primary/foreign key goes because those are concepts that doesn’t belong to the design stage. I know it sound weird but you should not think about tables as well ! (you could implement your E/R model using XML/Files/Whatever
Sticking to E/R relationship design you should just indentify your entity (in your case Company/supplier/utilities/vanInfo) and then think about what kind of relationship there is between them(if there are any). For example you said the company can have one or more VanInfo but the Van Info can belong only to one Company. We are talking about a one – to- many relationship as you have already guessed. At this point when you “convert” you design model (a one-to many relationship) to a Database table you will know where to put the keys/ foreign keys. In the case of a one-to-Many relationship the foreign key should go to the “Many” side. In this case the van info will have a foreign keys to company (so the vaninfo table will contain the company id) . You have to follow this way for all the others tables
Have a look at the link below:
https://homepages.westminster.org.uk/it_new/BTEC%20Development/Advanced/Advanced%20Data%20Handling/ERdiagrams/build.htm
Consider making Com, Sup and Util PKs a GUID, this should be enough to solve the problem. However this sutiation may be a good indicator of poor database design, but to propose a different solution one should know more broad database context, i.e. that you are trying to achive. To me this seems like a VanInfo should be just a separate entity for each of the tables (yes, exact duplicate like Com_VanInfo, Sup_VanInfo etc), unless VanInfo isn't shared between this entities (then relationships should be inverted, i.e. Com, Sup and Util should contain FK for VanInfo).
Your database basically need normalization and I think you're database should be on its fifth normal form where you have two tables linked by one table. Please see this article, this will help you:
http://en.wikipedia.org/wiki/Fifth_normal_form
You may also want to see this, database normalization:
http://en.wikipedia.org/wiki/Database_normalization