Are there generally accepted computer science terms for one-to-one and one-to-many relationships? Something similar to the terms "aggregation", "generalization", and "association," but strictly pertaining to the cardinality of the relationship?
From everything I've ever read, one-to-one, one-to-many, etc. are the accepted ways of referring to these relationships. They are very self descriptive of what they're about.
Related
Entity-Relationship is confusing me. In some examples I couldn't find relationship between some entities, in other words I can't track information between them.
My question is
"Is it necessary to have relationship between all entities in database. In other words, is it ok to have diagram without relationship, whether there is no relation, whether for simplicity"
Thanks in advance
Logically, entities are implicitly related by attributes having the same domain, and a database can be understood as a set of related data. Thus, on the logical level, I believe that all entities in a database must necessarily be related.
On an ER diagram, however, the absence of relationship lines make it difficult to determine the foreign key domains, cardinality and constraints. It's bad enough that most ER diagrams show physical types and not domains, and that most are poorly normalized. Without any hint of dependencies, all we have is a visual table dump.
Where there is no direct relationship between two entities, no indication is required. It's fine to show subsets of a schema in a diagram, to focus on particular aspects, as long as the missing information is indicated elsewhere. Leaving out important and necessary information is not acceptable, though.
Is it possible to tell if a database is normalised just by looking at the ERM? What assumptions do you have just by looking at the ERM
Entity Relationship (ER) diagram will give you an idea about relationships between entities and helps in making assumptions about normalization, but does not guarantee that normalization was done. Looking at the structure, data and relationships (foreign keys) will confirm normalization.
Some assumptions:
1NF may have been applied. Customers, sales people, orders, payments etch. appear to be well separated
Foreign keys may have been applied since one-many relationships are displayed
Primary keys may have been used
Information can be tracked from supplier through to the customer, which may make product recall easier
I am trying to write out a database design to include the following relationships, I have tried to work them out from the top down, hierarchically, but the relationships seem to be better connected another way, I just cannot see, or express how.
(This comes from a FOUO system from work, so the names have been changed to reflect that classification, that's why the names may look odd.)
Each Branch 1:n Functional Areas,
Each Building 1:n Groups,
Each Group 1:n Units,
Each FunctionalArea 1:n Checklists,
Each Checklist 1:n Items, and
Each Unit 1:n Checklists and
This was solved by re-evaluating the relationships without concern for the size or data type they would hold. 1:n relationships were used in lieu of n:n.
When you are designing a database you need to be specific about the relationships. For example you need to mention things like "A functional area can only belongs to a one branch only". These will help to determine either we are going to have 1:1 relations or 1:n or something else.
However i have come up with an answer.
one simple way I've used that would handle this is to have tables for each pairing: branch-function, building-function, building-group, group-unit, unit-checklist, checklist-item, keeping the objects and relationships separate.
It's basically tuple soup, but keeping that sorted is what a relational db is good at. Accesses will be doing primary-key joins on multiple tables. How large do you expect your dataset to grow?
The limits (100 checklists, etc) are policy. Design the schema for simplicity and performance, implement policy in the application layer.
At an introductory level, is there a simple way to understand normalization to 3NF? To attempt to explain my confusion, I have an example table that has affiliated political party codes along with description, description of being congressman or senator along with codes for each, names of 4 individuals, and 4 examples of a bill voted on and yes or no of individuals vote. Each has date of voted and I have to allow for additional entry of various bills in future tobe voted on. I have to enforce referential integrity. I am not asking for the answer, but when attempting to normalize, do I have to enforce integrity on each table? I am missing something to understanding how to normalize tables to 3NF.
I have a hierarchical data structure which, as far as I can see, needs to have a series of successive many-to-many relationships.
It goes something like this:
Company
Account
Treaty
Benefit
Policy
Person
With the following relationships:
Company 1---8 Account
Account 1---8 Treaty
...all still fun
And then, many to many:
Treaty 8---8 Benefit, so I create the relational table TreatyBenefit, and do:
Treaty 1---8 TreatyBenefit 8---1 Benefit
Now, for a specific Treaty and a specific Benefit (i.e. a TreatyBenefit) there can be many Policies. But again, a single policy can also fall under multiple TreatyBenefits
So, then I have TreatyBenefit 1---8 TreatyBenefitPolicy 8---1 Policy
And then of course, the same applies to Person, so I also then get:
TreatyBenefitPolicy 1---8 TreatyBenefitPolicyPerson 8---1 Person
What I would like to know is if there are any conventions for naming tables so that you can avoid names that become so long that they are essentially meaningless? Or are there better approaches to the design that avoids this kind of structure entirely?
Thanks
Karl
IMHO unless there are other strong, wideley accepted, meaningful business-centric names for these entities / concepts, then I would stick with the trusted Many:Many mangles that you've described above.
Also, each of the 6 entities you've listed are reasonably concise, so there seems little point in abbreviating e.g. Ben, Per, Pol, Acc, Co etc would cause more confusion than benefit.