CWM is data modeling
UML is object modeling.
Can someone explain the difference that a layman can understand?
Object Model: deals with object oriented "blue-print" of your system. This includes, class diagrams (classes you will be creating), relationship between these classes, methods in the classes, properties etc.
Data model: deals with entities at the database level. Like how the classes in the OM will get stored in the database, in which tables etc. So DM deals with Table schema, relationship between different tables (PKs, FKs) etc.
DM does not have complex OO features like polymorphism, inheritance, overloading etc which are usually listed in an OM.
As a rough example, two classes in the OM can get stored (mapped) to a single Table in the DM, like both Employee and Manager persons can be stored in a single DB table.
Data modeling deals with the design and creation of your database structure, ie. how the data is stored.
Object modeling deals with how the application interacts with the information received from an external source, e.g. an end-user, a database, a web service, etc.
Let's say, for example, you are tracking customer history for the sales department. The department needs the customer's name, address, phone, email, and purchase history.
In the data model, you define the tables and fields that will store each individual piece of data. In that definition, you may include information like the maximum length, data type or whether or not the data is required.
In the object model, in addition to enforcing the rules you set up in the data model, you may also add additional behaviors, such as making sure that the email address is formatted correctly, or capitalizing the first letter of the customer's first and last name. These type of rules tend to be more complex and detailed than the rules set within the data model.
At any rate, the purpose of the object model is to ease the management of the data within the application itself and to perform higher-level validation on the data before it gets sent to the database.
Related
I'm writing a financial application form. Angular Schema Forms is perfect for the kind of flexibility I need to make the forms.
I'm having a bit of trouble getting my head around the concept of a schema, in particular: should a schema relate to a single form, or all the forms in an app?
I have many types of Financial Products that a user can apply for.... Checking Account, Savings Account, Car Insurance, House, Pet, Gadget Insurance. Many of the fields in the various forms are common to all: Name, Date of Birth, Address. Some are specific to one form or a couple of forms (Car Registration Number).
Should I have one all-encompassing schema which contains definitions for all of the possible fields in all of my forms, and add/override them in the Form definition object? Or should each form contain its own Schema? Or even each page in each form?
And if its either of the latter two - how do I prevent duplication? DRY!
The Schema vs the UI Schema
The way I think of it is that the Schema represents a view of your data model and the UI Schema represents an editable version of the view. Can you write a view that includes all of your fields in the database, yes, but I'm more likely to look at the specifics of what data I need.
In my projects I generate a JSON Schema for each product/service I provide customers and I used the json-refs library to allow me to pre-process json schema references ($ref) so that I can re-use definitions.
In my case I have an order schema which includes only order related data, customer address, order related dates, etc... that every order will need. I also have a product schema for each product. I then include the order and product into a combined schema with $ref. Each product can have multiple sections and attributes which I also re-use across products.
Now in your case it would seem like my solution would fit as our data is similar, however I do not know what your back end library is. That said the new alpha versions of Angular Schema Form support $ref using json-ref on the client side, but I would still look for a back end solution if your stack has a supporting library or you are using NodeJS and can use json-ref.
I'm newbie to designing class diagrams.
As my application works as REST API, I would like to use DTO-DAO design patterns. For user registration module, DB contains 3 tables for user signon, profile and address.
Do I need to create 3 DTOs and corresponding DAOs to insert/update user signon, profile and address?
If so, what if I only one table is created instead of three tables and dropped two tables in future?
Whatever design pattern you follow, data modelling is entirely upto you.Your design pattern should be based on your data modelling and your need. Not that,your data model will depend on the design pattern but on your need
You can create whatever dto objects you like. However both your database design and your dto design is driven by the concepts in your system (user/company/address etc) this often called the domain.
You'll often find that the two are very similar, after all they both represent the same domain!
As to whether you need different dtos for different calls that really depends on you. Do you need a different class to represent an insert/update call? What's the difference? Often the update has an id (whereas the insert hasn't had one assigned yet). So why not have two where the update inherits from the insert but adds the id property?
Delete dtos, you can do these as either an update or just as an id. After all why bother to populate an entire object you're about tot delete. Personally I'd just say
DeleteUser(int id);
Much easier!
Every time I program I recognize this relationship between classes and tables, or am I imagining it.
You can have a class per database table or a table per class i.e. :
tables: customer, products, order.
classes: customer, products, order, may have methods such as addRecord, deleteRecord, updateRecord.
what is this called? Object-Relational? I am not a DBA.
It all depends on the type of database you're using. If you're using an object oriented database (OODB), then there is no relationship, as the objects and the persisted data are the same thing. For example, if you have a Customer class, and you save it in an OODB, then that instance of the customer is what is stored in the DB.
If you are using a relational database, then the class instances, and the persisted representation of them in the DB, can be the same thing, but many times they aren't. This is because most folks use normalization to represent their data in an efficient way (in a relational DB). This means, instead of having a table per class, you can have a class represented by more than one table. In the Customer example, the tables might now be Customer (with Name, date of birth, and other properties), and Order (with order pointing to products in yet another table). The reason for this has to do with cardinality, and the ability for Customers to have more than one order. When your business logic needs this information from the DB, the data access layer's job is to map the data (called ORM) from the DB into your classes.
If you are using yet another type of DB, then there will be a different relationship between the classes (domain model) and what's persisted in the DB.
But, as far as having a name for this relationship? No, there is no name.
In additon to Bob's answer, the following.
In object modeling, the relationship between classes and subclasses is taken care of by inheritance, and object modelers know how to use inheritance to good advantage. The relational data model and by extension the SQL databases do not implement inheritance for you. You have to design tables to give you some of the same results.
In ER (Entity-Relationship) modeling, the corresponding concept is called generalization/specialization. This tells you how to model a class/subclass relationship, but it doesn't tell you how to design the tables when you go to build your database.
There are three techniques that are pretty well understood that can be really helpful when dealing with classes and subclasses. Here are their tags: single-table-inheritance class-table-inheritance shared-primary-key. Unfortunately, many tutorials on database design never cover these techniques. They can be enormously useful to people who know object modeling and want to come up to speed on relational modeling.
I am trying to get Linq2SQL to work with my legacy database. I currently have a notes table that is generic to a few different entities and mapped m:m. Instead of mapping one relation table per entity type whoever designed this database decided to use a single relation table with a type column (as a varchar yuck!).
alt text http://img130.imageshack.us/img130/326/capturefm.png
How do I map Foo and Bar to have a Notes collection? Is this even possible. I am not seeing the light. I tried to have two classes FooNotes and BarNotes that inherit from RelateNotes and then mapping the Type field as the descriptor.
alt text http://img130.imageshack.us/img130/3153/capture2f.png
This doesn't work and I receive the below error.
Bad Storage property: '_EntityID' on member 'TestLinq.BarNotes.EntityID'.
I don't want to get too far down the Linq2SQL road before realising it not possible. I am not allowed to change the database much.
Many Thanks,
I would consider expanding your app's design to include a Domain Model based layered architecture.
This way you can create a Domain Model that meets the requirements of the system while abstracting away how the mapping works underneath. For example, you could have a common interface for the data access layer that returns the mapped entities. An implementation of this interface could be created for the old 'string-equality' m2m relationship in the legacy database. One day when you are ready to ditch the legacy database, a new implementation could be created for a different ER db model which would allow your Domain Model (object model) and higher layers (services, UI etc) to remain unchanged (because they all utilise the common interface).
In your object model you could define each object that needs Notes and have them each contain a Notes collection for each instance. Eg. Foo has a collection of Notes; Bar has a collection of Notes. Your Repository interface would look after returning these entities but the implementation of that repo would worry about how it's read and persisted to the db.
I asked about Choosing a method to store user profiles the other day and received an interesting response from David Thomas Garcia suggesting I use the Table Module design pattern. It looks like this is probably the direction I want to take. Everything I've turned up with Google seems to be fairly high level discussion, so if anyone could point me in the direction of some examples or give me a better idea of the nuts and bolts involved that would be awesome.
The best reference is "Patterns of Enterprise Application Architecture" by Martin Fowler:
Here's an excerpt from the section on Table Module:
A Table Module organizes domain
logic with one class per table in the
database, and a single instance of a
class contains the various procedures
that will act on the data. The
primary distinction with Domain
Model is that, if you have many
orders, a Domain Model will have one
order object per order while a Table
Module will have one object to handle
all orders.
Table Module would be particularly useful in the flexible database architecture you have described for your user profile data, basically the Entity-Attribute-Value design.
Typically, if you use Domain Model, each row in the underlying table becomes one object instance. Since you are storing user profile information in multiple rows, then you end up having to create many Domain Model objects, whereas what you really want is one object that encapsulates all the user properties.
Instead, the Table Module makes it easier for you to code logic that applies to multiple rows in the underlying database table. If you create a profile for a given user, you'd specify all those properties, and the Table Module class would have the code to translate that into a series of INSERT statements, one row per property.
$table->setUserProfile( $userid, array('firstname'=>'Kevin', 'lastname'=>'Loney') );
Likewise, querying a given user's profile would use the Table Module to map the multiple rows of the query result set to object members.
$hashArray = $table->getUserProfile( $userid );