In an application I'm writing I have a fairly complicated Database model. I'd like to use EF4 to map this to a whole lot nicer conceptual model. However all the tutorials I've read are with samples of 2 or 3 tables which all map 1 on 1 to the conceptual model.
I'd like to learn how to correctly map the database model to a different conceptual model using VS 2010. However I can't find any good tutorials or (preferabally) instruction video's.
Somebody got any tips, links or even books?
Here are some interesting mapping scenarios.
TPT, TPC, TPH hierarchy mapping
Entity splitting
Multiple entity sets per type.
Related
while studying, im struggling to find an answer to this question:
What is a generic datamodel?
Are there any alternatives to a generic datamodel, if so; which one would you recommend?
I've looked everywhere to find a decent answer, but i didn't find it. It might be just a very simple question, i just couldn't find these terms; 'generic datamodel'.
Perhaps by generic data model you mean an entity attribute value model: EAV on wikipedia
This data model has one table and three columns. It is usually burnt by fire if ever discovered by someone of a database (vs developer) persuasion.
The thing with a data model is that you are modeling something. You are applying your skills to build a database that is optimised to store and retrieve data about something (widgets in a factory, trades on a stock exchange, Facebook posts). A EAV can store all of this stuff but it causes many other problems down the line.
More info here: EAV
It could be possible its an EAV mode. But that leaves me with the following question: are there any alternatives to this model?
Thanks.
# nick, this is the question:
Advise in Chapter 5 of the people involved in your case about the application or not of a generic data model
and optionally other alternatives. Motivate your opinion (10 points).
Below is the ER diagram with relation among 5 different entities.
My question:
1)
Each of these 5 entities a class as per OOP terminology?
2)
Can you help me understand the meaning of relation(different types of lines) among these 5 entities? Line with a little bubble/ with an angular shape /text
This is not an UML diagram at all, but an entity-relationship (E-R) diagram and typically shows the DB design. You can easily google it to find the detailed notstional rules, I could quickly find this page:
http://www.google.de/imgres?imgurl=http://docs.oracle.com/cd/B12037_01/java.101/b12021/img/entity_d.gif&imgrefurl=http://docs.oracle.com/cd/B12037_01/java.101/b12021/dev.htm&h=1780&w=1556&tbnid=vbXfAtrAAIq5_M:&zoom=1&tbnh=97&tbnw=85&usg=__vyr0LMggQHqYtI8Q6Ix-722jJwg=&docid=3LbfUSlxwqfpMM&client=firefox-a&sa=X&ei=iX1HU5awEImN7Qbf6IGwDg&ved=0CEsQ9QEwBA&dur=1439
If you want to model DB in UML, you can still do it, using class diagram and eventually restricting permited relationships to those available in non-OO modelling.
I can barely count the number of times I've created a "users" table, similar for "computers" and "customers". I've tried looking around, but haven't ever seen a resource for modeling these schema that we see over and over again. It seems like some of these objects should be some-kind-of-solved by now. Is there anything like this?
I have never seen anything like this either and I'm not sure it's necessary. Yes, there are a lot of similarities but every application is different. At one point I had built an internal library of some of my more "standard" tables (user is a good example) to use as a jumping point, but I have yet to create two identical tables for different systems.
Thus, I have yet to ever use the library I built because I can write the new table quicker and more error free than I can modify another existing example to work for the current project.
You could look at the source code of some popular open-source CRM/ERPs, such as OpenERP, though some of them are not great.
These are the top books on data modelling patterns:
Analysis Patterns, Fowler
Data Model Resource Book, vol. 1,2,3, Silverston
Enterprise Model Patterns, Hay
Patterns of Data Modeling, Blaha
If I create an entity data model using the using the model first approach and building my model from an existing database is there a way that I could then automate the creation of partial classes to then allow me to extend the model to fit my requirements. So for example were I to model the Northwind Database then, amongst others, entities would be created for 'Customer' and 'Order'. I would like to find a way to then have visual studio to build a set of partial classes for each of the entities and put them into separate files.
I have no idea if this is doable in the first place, or if it is what the best way to go about doing it would be. To that end I would welcome any suggestions and / or good basic examples of where to start learning how do to this sort of thing. Ideally any such examples would have content in vb as well as c#.
Many thanks
I am a little bit confused about Dataset compared to ORM (NHibernate or Spring.Net). From my understanding the ORM sits between the application layer and the database layer. It will generate the SQL commands for the application layer. Is this the same as what Dataset does? What is the difference between the Dataset and ORM? What are the advantages and disadvantages for these two methods? Hope the experts in here can explain something.
Thanks,
Fakhrul
There is a BIG difference between them, first of all about the programming model they represent:
The Dataset is based on a Table Model
An ORM (without specify a particular product of framework) is based and tends to a Domain Model.
There is another kind of tool which could be used in data scenario, this kind of tool is a Data Mapper (eg. iBatis.NET)
As others answers before me, I think it's important to view what Microsoft says about Dataset and better what Wikipedia says about ORM, but I think (this was for me at beginning) it's more to understand the difference between them in terms of model. Understanding that will not only clarify the choises behind but better, will do too easy to approach and understand a tool itself.
As little explanation it's possible to say:
Table Model
is a model which tends to represent tabular data in a memory structure as close as possible (and even as needed). So it's easy to find implementations which implements concepts as Table, Columns, Relations in fact the model is concetrate on the table structure, so object orientation is based on that not on data itself. This model could has its own advantages, but in some case could be heavy to manage and difficult to apply concepts on contained data. As previous answers says, implementations like Dataset, let, or better, force you to prepare (even if with a tool) needed SQL instructions to perform actions over the data.
ORM
is a model which (as mendelt says before me..) where Objects are mapped directly to database objects, principally Tables and Views (even if it's possible to map even functions and procedures too). This is done in 2 ways generally, with a mapping file which describes the mapping, or with (in case of .NET or Java) code Attributes. This model is based on Objects which represents the data, so object orientation could be done on them as in normal programs, it's clear with more attention and caution in certain cases, but generally, when you are confident with ORM it could be a really powerfull tool! Even ORM could be heavy to manage if it's not managed and designed well, or better understood weel, so it's important to understand techniques, but I can say with my experience that ORM is a really powerfull tool. In ORM, the tool principally it's responsible to generate the SQL instructions needed as operations are done in code, and in more cases ORMs has a middle language (like HQL) to perform operations on Objects.
MAPPER
A mapper is a tool which doesn't makes things like an ORM, but, maps hand written SQL instructions to an Object Model. Thi kind of tool could be a better solution when it's needed to write by hand SQL instructions but It's wanted to designe an application Object model to represent data.
In this "model" objects are mapped to instruction and described in a mapping file (generally an Xml file as iBatis.Net or iBATIS (java) does). A mapper let you define granular rules in SQL instructions. In this scenario could be easy to find some ORM concepts as for example session management.
ORM and Mappers let to apply some very interesting Design Patterns, which could be not so easy to apply in the same way to a Table Model and in this case to a Dataset.
First of all excuse me for this long answer and about my poor english, but for me, an answer like this makes me in past to understand well the difference between this models and then between implementations.
the Dataset class is definitly not an ORM; an ORM maps relational data with an object oriented representation.
It can be regarded as some kind of 'unit of work' though, since it keeps track of the rows that have to be deleted/updated/inserted.
ADO.NET DataSet =
http://msdn.microsoft.com/en-us/library/zb0sdh0b(VS.80).aspx
ORM =
http://en.wikipedia.org/wiki/Object-relational_mapping
(Example Developer Express
XPO,DataObjects.NET)
ORM is based on mapping between objects and tables. Not the case for this dataset. Dataset is itself in a way directly to the table. ORM is based on a minimum of SQL script. But enough to use the dataset you write SQL clause. Dataset in this case is not an ORM.
Look at dataset and ORM.
No, Datasets are not ORM's. They may look like orms because datasets map tables to objects just like ORM's the main difference lies in what objects they map to.
Datasets have their own table and row object types that closely resemble the structure of the database. You're rebuilding part of the database's relational model in objects. Restricting these objects into something resembling a relational database gets around some of the problems inherent in mapping a database to an object model.
An ORM maps the tables and rows from the database into your own object model. The structure of your object model can be optimized for your application instead of resembling a relational database. The ORM takes care of the difficulties in transforming a relational model into an object model.
DataSet is a DTO, a data transfer object. DataSet itself can't do anything. You can use a DataAdapter (of the provider used) to produce sql or call predefined queries, though it still isn't doing anything.