I've downloaded MySQL workbench and can create a EER diagram.
What's the difference between this and a UML diagram?
Where does a ERD come into this?
I think by UML diagram you mean : UML Class Diagram. [ there are other UML diagrams also]
EER (Enhanced entity–relationship) Diagram-Model
Used for Database Design. Like class diagrams support also subclass -superclass [specialization and generalization]. So entities in EER diagrams has attributes not methods.Because they show just plain data.
Note: ER [entity–relationship] Diagrams are origin of EER. They are from Structured Analysis. Also used for database modeling.How ER become to EER? I think because of Object Oriented Style Hype.
UML Class Diagrams
Used for Object Oriented Analysis-Design.
Can be used to model databases also : there are UML class profiles for it.
[I think UML profiles for Database Designs are NOT good as ER diagrams]
But in simple terms classes are blueprints in which objects instantinated . So classes may have methods-functions as well as attributes.Software classes definitely has methods but conceptual classes[ used for domain modeling] may not.
The primary difference between ERD and UML is that ERD stands for Entity Relationship Diagram, a type of diagram (as explained above), while UML stands for Uniform Modeling Language, which is essentially a standard defining a modeling language commonly used in software development, especially in Object Oriented Program.
UML also proposes standard diagram types (as noted above), usually grouped into structural or behavioral diagrams. Most DB GUIs use ERDs, which are better suited for the domain and most users don't need formal, academic diagrams.
Note that most software teams like to site UML as a reference; yet, don't usually implement UML to full spec or with academic rigor when creating documentation diagrams.
As a rule of thumb, if you want to model DB entities/relationships you are probably looking for an ERD but if you want to model an entire program/system then you probably need one-many of the different UML diagrams.
Related
There seems to be any amount of RDF-format for the OSLC but what I'm looking for is a simple E-R-like view of the OSLC metamodel which shows the concepts and relationships which can be used to understand the organisation and possible queries.
Is there a (graphic) representation of the OSLC metamodel anywhere?
If you are after a simple graphical diagram, you can find UML models under this Lyo-Docs
repo. you can find the source .emx files, as well as .png snapshots under the folder "OSLC-V2/images/".
I you are developing OSLC applications, you might want to consider the modelling tool Lyo Designer.
There, you can find a graphical model of the OSLC Core and Domain concepts. The models are based on a OSLC-specific modelling language. Lyo Designer allows you define/extend your own models, from which you can generate an OSLC application, based on the Eclipse Lyo SDK.
I here assume you are aware of the java class implementations of the OSLC Core concepts in Eclipse Lyo. There is also an implementation of the domain specifications.
I'm currently working on modeling context for a context-aware application.
The better choice seems to be ontologies, however object oriented models and relation data bases, seem to have some advantages too.
An author (Jagdev Bhogal and Philip Moore) in particular used object-relational databases to model context and claim that:
The ORDBMS approach provides limited inferencing. A subtype
definition has access to the representation of all of its direct
supertypes (but only within the ADT definition that defines
the subtype of that supertype), but it has no access to the
representation of its sibling types. 〈…〉 Such functionality would
need to be manually programmed when developing the application
interface.
I'm new to this subject, and it seems to me that you could make very complex queries to retrieve almost any information, but I've never used ontologies before.
So: in what way do object-relational databases, or even regular relational databases, provide limited inferencing, when compared to the use of ontologies (e.g. OWL Description Logic)?
I have:
class Settings{
static int temperature;
}
Tables roughly corrospond to object instances how do you represent static data
What's is a correct way to implementing this kind of behaviour in an RDBMS ?
This type of mapping is one of the conceptual and technical difficulties that are often encountered when a relational database management system is being used by a program written in an object-oriented programming language.
A major mismatch between existing relational and OO languages is the type system differences. The relational model strictly prohibits by-reference attributes, whereas OO languages embrace and expect by-reference behavior. Scalar types and their operator semantics can be vastly different between the models, causing problems in mapping.
It has been argued, by Christopher J. Date and others that a native mapping between classes and relational schema is a fundamental design mistake
See Object relational impedance mismatch.
My newly created system was created using the Model Driven Architecture approach so all I have is the model (let's say comprehensive 'Order' and 'Product' classes). These are fully tested classes that support the business of my application. Now it's time to persist these classes as objects on the harddrive and at some later time retrieve them in the same state (thinking very abstractly here). Typically I'd create an IOrderRepository interface and eventually a ADO.NET-driven OrderRepository class with methods such as GetAll(), GetById(), Save(), etc... or at some point a BinaryFormatter-driven OrderRepostiroy class that serves a similar purpose through this same common interface.
Is this approach just not conducive to LINQ-To-Sql or the Entity Framework. Something that attempts to build my model from a pre-existing DB structure just seems wrong. Could I take advantage of these technologies but retain this 'MDA' approach to software engineering?
... notice I did not mention that this was a Web App. It may or may not be -- and shouldn't matter.
In general, I think that you should not make types implementing business methods and types used for O/R mapping the same type. I think this violates the single responsibility principle. The point of your entity types is to bridge the gap between relational space and object space. The point of your business types is to have collections of testable behavior. Instead, I would suggest that you project from your entity types onto your business types when materializing objects from the database. Separating these two allows your business methods and data mappings to evolve independently, which is very important, especially if you cannot always control the schema of the database. I explain this idea more fully in this presentation.
I found this diagram in the JSON specification:
(source: json.org)
Where does this diagramming convention come from? Is it just some random convention cooked up by D.C.?
That's called a railroad diagram. Have a look at the wikipedia article for more information.
That diagram is known as a syntax diagram or railroad diagram. It's used to visually represent context-free grammars. It's a graphical depiction of the Extended Backus-Naur Form, which is also used to represent context-free grammars.