I have an ERD that I have developed relational model for. I just wanted to know if there are any errors in my relation model. I have listed the relational model below. I have a picture of the ERD.
PHYSICIAN (DRID (PK), NAME, SPECIALTY, PRESCRIPTION(FK))
PRESCRIPTION (PRESCRIPTIONID(PK), DRID(FK), DRUGID(FK), PATIENTID, DRUGDOSAGE)
DRUG (DRUGID(PK), DRUGNAME, DRUGMANU, DRID)
ORDERS (DRUGID(PK), PRESCRIPTIONID(FK))
I can see a few issues in your ERD:
Why does Prescription have a double-bordered box? It's not a weak entity set, it's identified by its own attributes.
Instead of showing Patient ID as an attribute of Prescription, draw a relationship between Prescription and Patient.
The ternary relationship Orders allows different physicians to prescribe drugs on the same prescription. Two binary relationships (many-to-one from Prescription to Physician, and a many-to-many between Prescription and Drug) should work better. In fact, your relational model almost does this already.
Should each prescription record only one Drug Dosage? I would place this attribute on the suggested binary relationship between Prescription and Drug.
As for your relational model:
If you include PRESCRIPTION in PHYSICIAN, this creates a functional dependency DRID -> PRESCRIPTION, in other words, each physician is associated with a single prescription. This is independent of PRESCRIPTIONID -> DRID in the Prescription table, which properly represents the binary relationship I suggested above.
If you include DRUGID in PRESCRIPTION, this creates a functional dependency PRESCRIPTIONID -> DRUGID, in other words, each prescription is associated with a single drug. This is independent of the association between drugs and prescriptions in the ORDERS table.
If you include DRID in DRUG, this creates a functional dependency DRUGID -> DRID, in other words, each drug is associated with a single physician. The physician for each drug in a prescription can be determined by joining PRESCRIPTION with ORDERS, no need to try and record it per drug.
ORDERS should use a composite primary key (DRUGID, PRESCRIPTIONID) to represent a many-to-many relationship. As it stands, each drug can be associated with a single prescription.
I hope that helps.
Related
I need to create a subdimension in icCube, for example:
I have two dimensions, the dimension Student and the dimension Localization. The dimension Student has a foreign key from Localization dimension and the fact table join with student dimension. Also I want create a hierarchy in student dimension with attributes from localization dimension.
Example of the model with localization as subdimension :
You've two options.
One dimension / two hierarchies
You would create a table that is the result of the crossjoin of Student and Localization (in the upcoming icCube version we've a join view). You'll use this
table to create a Dimension Student that has two hierarchies Student and Localization. Check Exists to see implication (it's usually not very important).
With this you only need to link Students to the facts as the relaction between facts and localization is solved through students ( it handles one-to-many too).
Two dimensions
You can create two dimension. One for Student and the other of Localization. Both are independent.
To bind the fact to the location we need to use an intermediate mapping structure that can be directly defined in the facts (it's called 'bridge', see Time). The bridge table would be STUDENT, ID_STUDENT, ID, ID_LOCALIZATION, this helps to build a mapping between ID_STUDENT and ID_LOCALIZATION (that might be many-to-many)
hope it helps
ERD from Wikipedia:
I'm confused to distinguish "has" and "contains" relationship in ERD, what's the difference between them?
With regards to the linked diagram from Wikipedia, both Has and Contains are one-to-many relationships (1..n) with total participation of Character in the relationship (double association line). Total participation means every Character must be related to an Account and a Region.
However, the Has relationship is marked as an identifying relationship (double-bordered diamond) and Character is marked as a weak entity set (double-bordered rectangle). This means that the identifying attributes of Character include the identifying attributes of Account. Character has a weak key CharName, which must be combined with AcctName to fully identify a Character. In other words, the primary key of the Character table will be composite: AcctName, CharName.
Note that these comments apply to the example ERD, not to ERD in general. Has and Contains aren't types of relationships - in general, a relationship can be called anything and have any combination of the features available in ER theory.
Also, see my answer to Is optionality (mandatory, optional) and participation (total, partial) are same?
I am about to develop a solution for a customer where the basic entity is a member and members can have different multiple social relationships with other members. For instance Lets say we have four types of members Doctors, Specialist, Nurses and Patients. So one or more Doctors can consult one or more Specialists, One or more Doctors can treat one or more Patients. One or more Doctor is in Charge of one or more Nurses. So if I were to use a Relational DB a high degree of recursion would be necessary (as All entities must be members). Whereas recursion is not necessary in a Graph data model.
Is it then safe to say it is better to use a Graph database for a social type application where members may have different or overlapping roles.
A graph database would be good at modelling these kinds of relationships. There's a few ways that you might model it. You could think of a vertex as being a Member with different edges from Member to other Members representing the types of relationships:
Member --consults--> Member (physician to specialist)
Member --reportsTo--> Member (nurse to physician)
Member --diagnoses--> Member (physician to patient)
Obviously a Member may have as many of any edge type (e.g. multiple "consults" with specialists). In a more complex model, you might also see a Member as being an "identity" for a person such that your model looks like:
Member --actsAsPhysician--> Physician
Member --actsAsSpecialist--> Specialist
Physician --consults--> Specialist
In this approach the "consults" edge can only exist on a "Physician" vertex, thus you provide some constraints as to what vertex types can be expected to have what kind of edges.
Graphs provide you a lot of flexibility in being able to model data such as it exists in the real-world as you are really just describing entities and the relationships among them. I'd encourage you to look at http://tinkerpop.com for a collection of tools that are helpful in building graph applications independent of the graph database you choose.
If every one is a member then member is central to the data model in a relational perspective. There is no need for recursive SQL select statements:
Member ->---<- Doctor ->---<- Patients
One or More Members is One or More Doctors One or More Doctors treats One or More Patients
Your model will have a lot of Many to Many relationships and alot of Relationship tables. For instance the Treats relation could contain attributes such as Treatment Period
Ailment
etc.
Your solution could be implemented in any topology. While the network/graph topology is faster than the Set topology the graph data model once implemented is almost impossible to change. History tells us it is unwise to build rigid business applications. So research the pros and cons of each and make a decision.
Am making a cube in SQL Server Analysis Services 2005 and have a question about many to many relationships.
I have a many to many relationship between two entities that contains an additional descriptive column as part of the relationship.
I understand that I may need to a bridge table to model the relationship but I am not sure where to store the additional column - in the bridge table or elsewhere?
Many To Many relationsip in SSAS can be implemented via an intermediate fact table that contains both dimension key that subject to the relation.
For example; If you have a cube that has a book-sales-fact table and you want to aggregate total sales by author (which may have many books and a book may be written by many authors) you should also have a author-book intermediate fact table (just like in relational database world). In this bridge table, you should have both dimension keys (Author and Book) plus some measure related to the current book and author such as wages paid to the author to write the book (or chapters).
As a result, if your additional column is kind of a measure you should add that column to the intermediate fact table.
I need a mental process to design an OLAP database...
Essentially for standard relational it'd be (loosely):
Identify Entities
Identify Relationships
Identify Properties of Entities
For each property:
Ensure property can be related to only one entity
Ensure property is directly related to entity
For OLAP databases, I understand the terminology, the motivation and the structure; however, I have no clue as to how to decompose my relational model into an OLAP model.
Identify Dimensions (or By's)
These are anything that you may want to analyse/group your report by. Every table in the source database is a potential Dimension. Dimensions should be hierarchical if possible, e.g. your Date dimension should have a year,month,day hierarchy, Similarly Location should have for example Country, Region, City hierarchy. This will allow your OLAP tool to more efficiently calculate aggregations.
Identify Measures
These are the KPI's or the actual numerical information your client wants to see, these are usually capable of being aggregated, therefore any non flag, non key numeric field in the source database is a potential measure.
Arrange in star schema, with Measures in the center 'Fact' table, and FK relations to applicable Dimension tables. Measures should be stored at the lowest dimension hierarchy level.
Identify the 'Grain' of the fact table, this is essentially the 'level of detail' held. It is usually determined by the reporting requirements, the data granularity available in the source and performance requirements of the reporting solution.You may identify the grain as you go, or you may approach it as a final step once all the important data has been identified. I tend to have a final step to ensure the grain is consistent between my fact tables.
The final step is identifying slowly changing dimensions, and the requirements for these. For example if the customer dimension includes an element of their address and they move, how is that to be handled.
One important point in identify the Dimensions and Measures is the final cardinality that you are electing for the model.
Let´s say that your relational database data entry is during all day.
Maybe you don´t need to visualize or aggregate the measures by hour, even by day. You can choose a week granularity or monthly etc.