Can anyone specifically differentiate when it is appropriate to use the http://schema.org/MedicalClinic versus the http://schema.org/Physician.
The schema.org defines each as:
Physician - A doctor's office
MedicalClinic - A medical clinic
The issue of contention: To my understanding a medical clinic is a medical business that consists of multiple physicians and other credentialed individuals.
However, isn't it possible for a physician to work for a medical clinic that's made up of a single physician & other professionals? In the case, one physician & other credentialed individuals, is it a clinic or an office?
Does clinic imply the act of treatment whereas office implies solely the act of diagnosis?
Can anyone clear this up for me?
From a practical point of view, after comparing both schemas:
both inherits Thing > Organization > LocalBusiness > MedicalOrganization properties
Each type properties
MedicalClinic:
availableService
medicalSpecialty
Physician
availableService
medicalSpecialty
hospitalAffiliation
So the only difference is hospitalAffiliation which is of Thing > Place > CivicStructure > Hospital type.
So if it is appropriate to fill the property hospitalAffiliation with a Hospital type use the http://schema.org/Physician, if it has no sense to use it, use the http://schema.org/MedicalClinic type.
Related
This question already has answers here:
How can you represent inheritance in a database?
(7 answers)
Closed 2 years ago.
I am building a Postgres database which has the following two tables:
Projects (id, startDate, etc...)
and
Employees (id, name, etc...)
I want to keep track of the types of contributions that an employee adds to a project. For example, employee #1 might be an "engineer" on project 1 and a "manager" on project 2. I also don't want to restrict the number of contributions an employee can make to a certain project. So employee #1 could be both a "engineer" and a "manager" for a single project.
My first instinct was just to have a many to many relation between the two titled ProjectEmployees or something and store the projectId, employeeId, and a contributionType as a string which would only take on values from an enum as to not have to deal with misspellings or any related issues.
My main question is just whether or not this is a bad practice. My other thought was to split up each contribution type to its own table. So instead of an EmployeeProjects table, there would be tables such as ProjectEngineers, ProjectManagers, etc... and instead of storing the contributionType as a column, it would be implicit in the table I'm using, and the table only has to store projectId and employeeId. There are many more tables in this database which have a similar sort of relationship where there are many to many relations between different tables, but each relation could be one of many "types" of relations. Is it wiser to split these all into separate tables for each type of relation? Or is it better to just keep track of the relation type in a more general table like my first idea?
My desired result is to just be able to efficiently see which all project contributions (and types) an employee worked on as well as to see all contributors + contributor types for a project.
Use the many to many relation as in your first idea, which in my opinion is a good practice.
Avoid the creation of one table per contribution type as is not scalable and flexible. I.E. if one day you'll have a new contribution type, with the 2nd option you will need each time
to create a new table
to write the new table management logic
proceed with a new deploy of your sw
About the topic of storing the contribution types on a table (with id and description) or as a constraint with contribution types strings enumerated, in my opinion both are valuable solutions.
But if you think to manage contribution types in your software (in a first release or in the future) maybe having a table with contribution types anagraphics can be better. It depends by your design and requirements
Make a table to store contribution types as strings (manager, engineer, etc) and contribution type id (numeric id). This prevents misspellings.
Make a table to store contributions with columns: employee id, project id, contribution type id (you may want other columns there, but it should be unique on the combination of these 3 columns). Do not store contribution types as strings in a table like this, since, as you correctly mentioned, this may allow misspellings. Another reason is to save disk space. An extra join with a small table of contribution types is a small price to pay.
The entity is a person.
So the entity have a birthdate and maybe already have a deathdate.
But this dates can or cannot be informed (depends of the entity and avaibility of the informations) ; so the entity might have none of those.
But I feel to do mess with the cardinality and the relation type.
How should I represent that ?
I have created an abstract class Individual. It leads to 2 final class : Person (identified person) or Pseudonym (anonym person).
It linked to a class Birthdate and a class Deathdate (both are generalized as a class Date).
[Birthdate]----<>[Individual] relationship is :
one (optional)-to-many (0..1 - 1..*)
0..1 : Because birthdate can be omitted and individual can have just one date of birth.
1..* : Because birthdate must concern at least one, but can concern severals individual.
[Deathdate]----<>[Individual] relationship is :
one (optional)-to-many (0..1 - 1..*)
0..1 : Because the individual isn't dead yet and can die just once.
1..* : Because deathdate must concern at least one but can concern severals individual.
But since, theoretically, everyone have a birthdate (and will have a deathdate) I was tempted by a composition. But some might prefer keep these dates secret and I wondered if composition could allow that.
Futhermore one date can correspond to severals individuals and here also I guess composition isn't possible then OR else it's me who did the confusion between Individual class and its instances (the individuals) and then Composition would be possible but not with the aforementionned cardinality.
At the moment I chose that :
Aggregation :
___________ _______________
|Birthdate|0..1-----1..*< >| |
___________ | <<Individual>>|
|Deathdate|0..1-----1..*< >|_______________|
But I hesitate with this one
Composition :
___________ _______________
|Birthdate|0..1-----1<#>| |
___________ | <<Individual>>|
|Deathdate|0..1-----1<#>|_______________|
What is the right answer ? Thanks for the attention.
There is a number of issues with the approach.
First - using a class for dates is simply an overkill. Both birthdate and deathdate are attributes of a specific person and can be easily modelled as inline properties of the Individual class. Unless there is some significant reason to use something more than the good old Date DataType, keep with the standard approach.
For visibility issue, as object oriented principles say you should not expose the properties directly anyway. Rather than that you should have an operation responsible for retrieving birthdate and deathdate that will control if the date can be read or not. You may add boolean attributes that will support that, but it isn't necessary if the ability to see the dates depend on some state of the Individual or other things (e.g. "who" asks). In the former case you may also wish to still show explicitly those boolean attributes as derived ones.
If you insist on using a class for dates (e.g. as you want to have a Wikipedia-style "Born on date"/"Deceased on date" collections) you should create just one class Date and build associations to this class pretty much similar to the way you did in your second approach. In such situation, the multiplicity does not work "database style" but is a property of association itself. In particular association you have one birthdate/deathdate and one Individual. By default you will have two 1-0..1 association one for each but depending on the approach you may have much more complex approach as well.
I'll later add diagrams for more clarity.
One last remark.
Do not use << >> for the class name. Those are reserved to indicate stereotypes.
If you want to indicate that Individual is abstract either show it in italics or (if your tool doesn't allow that) use <<abstract>> stereotype.
I am trying to do a simple UML model about a car dealership.
The company has at least one store where in each they sell at least one type of a car. Each store has a name and each car has a name, type, and price. Each outlet also keeps stock of every car they sell.
I have outlined the idea in this image:
In addition to this, after every day, the number of cars sold gets recorded into a database. How would I add this to the model? Also, is there a better way to model the amount of cars in stock than to have it as a separate class? If there is a better diagram to model this type of scenario with I'd also be interested.
Thanks for any help!
There are many ways to model sales records. The simplest and most common is to have a sales ledger. It creates sales entries for items. The item is a separate (association) class that records the number of sold items, the price paid, the sales date, the sales person, and more. Pretty simple and straight forwards, until you get to the gory details. Ask your next dealer...
You can model a sales record as a separate class. Let's call it DaySales. Each day, you have a new instance of DaySales, containing the date and the amount of cars sold. I have given attribute date the data type 'String', because UML does not define a Date type. But if you define it yourself, you could better use Date than String.
I have removed the association between Car and Outlet, because it is already implicitly defined via Stock, but you can keep it as a redundant association, if you like.
I have altered the multiplicity of the association between Car and Stock, because there will be multiple cars in stock.
I am currently trying to model a MongoDB database structure where the entities are very complex in relation to each other.
In my current collections, MongoDB queries are difficult or impossible to put into a single aggregation. Incidentally, I'm not a database specialist and have been working with MongoDB for only about half a year.
To keep it as simple as possible but necessary, this is my challenge:
I have newspaper articles that contain simple keywords, works (oevres, books, movies), persons and linked combinations of works and persons. In addition, the same people appear under different names in different articles.
Later, on the person view I want to show the following:
the links of the person with name and work and the respective articles
the articles in which the person appears without a work (by name)
the other keywords that are still in the article
In my structure I want to avoid that entities such as people occur multiple times. So these are my current collections:
Article
id
title
keywordRelations
KeywordRelation
id
type (single or combination)
simpleKeywordId (optional)
personNameConnectionIds (optional)
workIds (optional)
SimpleKeyword
id
value
PersonNameConnection
id
personId
nameInArticleId
Person
id
firstname
lastname
NameInArticle
id
name
type (e.g. abbreviation, synonyme)
Work
id
title
To meet the requirements, I would always have to create queries that range over 3 to 4 tables. Is that possible and useful with MongoDB?
Or is there an easier way and structure to achieve that?
Dear helpers and saviors !
I'm trying to create some dynamic forms with Silex.
My objective is to have the user create a state in a existing country. I would like him/her to select a region (like Asia, Europe, America...), then select a country to which link the newly created state.
I have some "classic" and simple forms extending AbstractType, in which the user can select the country directly. I created a choice list based on a call to a DAO (database) to find all available countries. I would like to add a region choice_list field to reduce the number of available country (and reduce the database charge as well even if it isn't my main goal).
I've seen http://symfony.com/doc/current/cookbook/form/dynamic_form_modification.html#cookbook-form-events-submitted-data, but it seem that we can't create subform for elements that are "parents" of the main class (or that i did not understood how), saying that the link is not stored in my object i would like to create. What i would like to do here is to add a field for the 2-level above (state->country->region), not direcly linked (a state have a country, and a country have a region) region.
I do not manage to imagine or code it properly, or even simply displaying.
Please note that i'll have to do it on several levels (state, city, and some other classes), and i would like to find a quite generic way to do it (understand not a ready solution for this particular example).
Any ideas ?
Please excuse my english, and thank you very much for your help !
For reference, here are my DB links between objects :
Region : ID and Name
Country : Codes, ID, Name and link to Region's ID
State : Codes, ID, Name and link to Country's ID
City : Name, ID and link to State's ID
I managed to do what i wanted.
I created supplementary forms, asking for filling each of the "parent" objects.
So in addition to my Types forms, i now have a selection a Select forms, allowing me to select Region, then Country, then State.