What are the differences between o-o DB and o-o programming languages?
Does o-o DB have all features in o-o programming like:
- Association
- polymorphism
- encapsulation
- Multiple inheritance
I couldn't find a direct answer to it
Initially there were procedural languages and data was stored relationally using foreign keys in tables.
After OOP languages were introduced the developer community observed mismatch between the two entities wiz OOP languages and DB. Since OOP concepts were not supported by the relational model. It caused lot of problems few of which are:
Granularity - Since clearly we can see there are always more classes than tables.
Identity - DB have concept like primary key but it's not there in OOP language
Associations - OOP supports has-a and is-a relationships but in relational DB we miss is-a relationship.
To provide a solution for this paradigm mismatch few vendors came up with OODB systems.
OODBS was more like an extension than an datastore. This provided seamless integration with OOPL. Unfortunately there didn't happen much work on standards for this type of DB and it lacked maturity to be popular among developers.
The solution which is popular today to part the mismatch between OOPL and relational DB is called ORM solutions like we have Hibernate for Java.
Related
I Want To Design OOP With Existing Data Base I have
Header,Details,linking Tables,Stored Proc which Retrieve
and calculate From Many Tables And Do Aggregates etc,
Am confused How To Convert All The Mess To OOP ?
A Relational Database (RDB) and Object-Oriented Programming (OOP) are different paradigms and techniques of each reflects a different purpose. A RDB is intended to efficiently store data in tables and quickly extract data and relations, while OOP is intended reflect the composition and abstraction of objects seen in the real-world. Being that the purpose of each is different, there is a logical gap between the two, but there is a great deal of work that has been done on converting from RDB to OOP and vice-versa.
This technique is called Object-Relational Mapping (ORM). There are a standard set of patterns and techniques that are used in ORM that can easily convert RDB data to OOP and vice-versa, but the specific techniques are beyond the scope of this post. In addition, Patterns of Enterprise Architecture has a very important list of techniques for bridging the gap between relational data and OOP, including:
Unit of Work Pattern
Query Object Pattern
Repository Pattern
In practice, these techniques are so common that many languages or popular frameworks have already codified these patterns, removing the need to manually implement them in a project. For example, in Java, there is Java Database Connectivity (JDBC) and Spring JDBC. The specific framework and tools will depend on the language, but most modern languages have a database (specifically relational database) mapping tools that remove the need to write tedious procedures to extract and store data. If you are interested, there is a list (albeit not comprehensive) of ORMs by language at List of object-relational mapping software.
Suggestion: Read and understand the common practices of ORM and then select a ORM or database abstraction framework that suits the need of your project.
Recommendations I understood in Java (which has a lot of restrictions, # least for me), even with hibernate was to have separated layers
Entities like persons, children, users, etc...
DAO entities linked to database
Service providing entities and functionalities, where I'll do the SQL
WebService providing an interface over needs
As I'm starting with Eiffel and store, I'm facing some difficulties I face since ever in programming (hoping there's somebody in this earth who has not the same problem) I always want to generalize things more than necessary. Every time I do a copy-paste, I refactor and look for a solution which makes me able to write it one time... which takes time and time on the delivery of the software, but for me adds more quality and flexibility to the software. I'm actually working alone in a company where I'm going to be the lead developer and if the future wants we'll be more developers. The goal is to develop a platform of services in Eiffel, postgresql-odbc, and an Angular-web front-end.
I'd like to have the more generic pattern to be able to manage entities in the future with typical situations as:
Database entities
Relationships
one_to_one
one_to_many
many_to_one
many_to_many
# The point I'm now, I'm about to develop an architecture which ideally for me has:
DB_ENTITY which as relations: BAG[RELATIONSHIP[P,S]] where P=Primary and S=Secondary
Primary is P->DB_ENTITY when ONE and BAG[P] when MANY
A COMPANY on my design will inherit from DB_ENTITY and add relationships as a BRANCH. So I was thinking having in my COMPANY class branches: RELATIONSHIP[like Current, BRANCH]
The relationship classes would help me to create the CRUD SQL statements into the "service" layer in a more abstract manner.
when I try something more lightweight I find restrictions in the pattern where I have to repeat operations... thats a bit my difficulty
Do you think of any disadvantages of such model I'm creating out of the first shot of development?
Quenio dos Santos not wanting to create an account on stackexchange, I'll quote its answer which could be useful for others
I recommend the book:
https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1540350158&sr=1-2&keywords=domain+driven+design&dpID=51OWGtzQLLL&preST=_SY445_QL70_&dpSrc=srch
Not just because of the Repository pattern.
You should be able to implement reusable, abstract classes out of the
repository pattern if you want to get away from repetitive code. In
Java, MyBatis is a framework that helps with that. I really don’t know
if there is anything equivalent in Eiffel. I’m also a new Eiffel
developer.
Some pros-and-cons of the Repository pattern:
You define the SQL yourself. Some see it as a cons, but some see it as a pros, because you have clear understanding of the mapping from
the database to your classes, and it allows you to optimize your
queries, and join several tables into a single class, or smaller
number of classes, when approriate in your context.
More freedom on how you define your domain model. It can be quite different from the schema of your database. Your classes don’t have to
be just a set of anemic attribute holders of the tables in your
database, but they can have behavior and be useful and expressive in a
setting completely independent from your database.
ORM frameworks, like Hibernate, are sometimes hard-to-use for a new developer not very familiar with them. With the repository pattern,
because the mapping is so clear and available in your own code, it
tends to be easier to understand and debug.
You can also have different implementations of your repositories for different technologies, such as NoSQL databases. With ORM frameworks,
you tend to be stuck with a relational database, unless you rework
quite a bit of your dependencies on the ORM framework. It is easier to
encapsulate the data store technology behind repositories, and keep a
clean separation between your domain model and your database.
I’d say those are the main points. Having said that, these are very
general guidelines. I don’t have any experience with data persistent
in Eiffel, so I couldn’t say what are the best practices for Eiffel
developers. But I have a gut feeling that the repository pattern fits
well Eiffel because the original goal of the language was to build
more abstract, domain-rich class libraries, which is the purpose
behind the repository pattern. (By the way, I’m calling it a pattern,
but I’m not sure the author calls it that. The author would probably
call aggregates, entities and repositories, all kinds of classes used
in domain-driven design, all together a pattern.)
I searched over .... I see many advantages, but it seems that all the advantages comes from a comparison over in-line SQL. I know in-line SQL is bad. But why compare with a bad one to show the other better?
If stored procedures are used (possibly exclusively), it seems none of the advantages still exists. Stored procedures definitely provide performance advantages in terms of security, performance (If a ORM can outrun a stored procedure, then the stored procedure is badly written) and a well written stored procedure is an automatic repository (pattern). Stored procedures can definitely provide better transaction and transaction isolation control.
I really appreciate an answer -- how ORM is better over a well architected application using stored procedures.
--- Thanks for all the answers that I receive so far ... It seems that the advantages still come from comparing using ORM's "dynamically generated SQL" with using "statically written in-line SQL" in the code. Yes, it has advantages. But it is not he question.
The question is better stated as the following:
If you consider having the stored procedures to implement your business logic (SPs can be written very advanced, and also very efficiently), in the Application code (.NET, JAVA), you have a very thin layer wrapper of the stored procedures organized by business need. My question is how ORM out-perform this architecture (Of course a well designed one).
ORM Tools make possible to develop abstraction layer between database and the model in the OO environment. The main advantage of this layer is that the developers who are not familiar with SQL can work with the model.
I have been seeking a good answer myself. Here is what I feel makes the difference:
1) ORM increases the developer productivity - mapping domain class to database is easier.
2) Stored Procs can potentially contain business logic - it is difficult to test these. This is mainly because of lack of tools/mocking framework.
3) ORM frameworks are tested ones which give you features like caching out of the box - no need to reinvent the wheel - and in most applications I've seen which do not use any ORM feature end up writing in-house Data Layer which ORM offers out of the box.
That being said - ORM does add some overhead as well, and it requires the developers to be aware of a new platform - writing efficient mapping comes with practise so there is a learning curve.
In the modern day setup, network bandwidth isn't as precious as rapid development and good quality (well tested) code. I guess this makes ORM well suited for database driven apps.
An ORM is a tool that can be used to build what you call a "well architected system". The idea is that when you are developing in a non-Relational language, there will be an impedance mismatch between the relational operation set provided by SQL/Stored Procedures and the language that you are using to build the rest of your application.
For developers using an object-oriented language (whether it is C++, C#, or Java) there are many considerations when mapping a complex relational schema into a rich Domain Model. It is certainly possible to perform all of this mapping in your own code, but as your interactions in this "no-man's-land" between OO and Relational paradigms grow more complex the more useful an ORM engine and associated tooling can be.
Some considerations as you plan out your mapping layer:
Do you need manage single-table or multi-table inheritance?
Do you want to leverage lazy loading?
Do you want to manually keep classes and tables synchronized or are you planning on using a tool to generate per-table classes (such as with a DataSet)?
Another consideration, especially when working in a team, is that when relational to domain layer mapping is performed by hand, there can be a great deal of variation in the way developers write the mapping. This can lead to inconsistencies, overlapping, and gaps that are difficult to detect. The selection of an ORM (especially a well known / solidly established ORM) can have an enormous (hopefully positive) impact on the solution and the pre-existing community surrounding that ORM will shape how you conceive of the mapping layer (you will find that there are significant cultural differences between Spring.NET and Entity Framework users, for instance).
Does an ORM make a good architecture? No. Are there systems whose architectures would be better off with an ORM? definitely. Are there projects that have been crippled by the unnecessary addition of an ORM? I'm guessing that there are many.
I suggest approaching this question from a different angle, and apply it to the specific application you are working on. Do you have any pain points by using SQL and/or Stored Procedures that an ORM might solve? Do you see any risks or have any concerns over problems that the introduction of an ORM might cause? Only by weighing the answers to these questions will you be able to determine if an ORM is a good fit for any given solution.
Why is multiple inheritance not supported in most of programming language?
I could really use this feature to develop different layout of application?
Multiple inheritance is useful in many situations as a developer, but it greatly increases the complexity of the language, which makes life harder for both the compiler developers and the programmers.
One problem occurs when two parent classes have data members or methods of the same name. It is difficult to resolve which is being referenced by the sub-class.
Another occurs when two parent classes inherit from the same base class, forming a "diamond" pattern in the inheritance hierarchy.
The order that the initialisation/elaboration of the parent classes needs to be specified - this can sometimes lead to behaviour changing when the order of the inheritance changes - something may catch developers by surprise.
Some languages support a reference to 'super', or equivalent, which refers to an attribute of the base class for this object. That becomes difficult to support in a language with multiple inheritance.
Some languages attempt to provide an automatic Object-Relational Model, so the objects can be made persistent with a regular RDMS. This mapping is difficult at the best of times (it has been described as the "Vietnam War" of software development), but it is much more difficult if multiple inheritance is supported.
One reason not to support it is ambiguity of method resolution.
http://en.wikipedia.org/wiki/Diamond_problem
However, I'm not sure what you mean by "most" programming languages. Many that are in use today support it directly (C++, Python, Perl, OCaml) or have a mechanism for similar functionality (Ruby and Scala come to mind).
The real reason why multiple inheritance is not supported across many langauges, is just the laziness of language developers. To cover up this embarrassing failure, all sorts of excuses are made, "it makes life difficult for the developer" bla bla, but for anyone who has actually used a language that implements it well, multiple inheritance becomes natural and easy after about 1 month. No big deal.
The only problem with it is after you have realized how useful and easy it is, you tend to become allergic to languages that don't support it and this may constrain your career prospects.
So my advice would be to stay well away from it.
I've worked with designing databases for a loooong time, and these days I'm working in C# too. OO makes sense to me, but I don't feel that I have a good grounding in the deep theory of OO design.
In database land, there's a lot of theory around how to design the structure of a database, the main notion being normalisation. Normalisation directly steers the structure of a database and to some extent dictates how to arrange entities in a database.
Are there any similar concepts behind how to design the structure of an Object-Oriented program?
What I'm reaching for is one or more underlying theoretical principles which naturally guide the developer into the "correct" design for the solution to a given problem.
Where can I look to find out more?
Is there a go-to work I should read?
Update:
Thanks to everyone for their answers.
What I'm reading seems to say that there is no "Grand Theory of OO Design", but there are a bunch of important principles - which are largely exemplified by design patterns.
Thanks again for your answers :)
Be careful some of the design patterns literature.
There are are several broad species of class definitions. Classes for persistent objects (which are like rows in relational tables) and collections (which are like the tables themselves) are one thing.
Some of the "Gang of Four" design patterns are more applicable to active, application objects, and less applicable to persistent objects. While you wrestle through something like Abstract Factory, you'll be missing some key points of OO design as it applies to persistent objects.
The Object Mentor What is Object-Oriented Design? page has mich of you really need to know to transition from relational design to OO design.
Normalization, BTW, isn't a blanket design principle that always applies to relational databases. Normalization applies when you have update transactions, to prevent update anomalies. It's a hack because relational databases are passive things; you either have to add processing (like methods in a class) or you have to pass a bunch of rules (normalization). In the data warehouse world, where updates are rare (or non-existent) that standard normalization rules aren't as relevant.
Consequently, there's no "normalize like this" for object data models.
In OO Design, perhaps the most important rule for designing persistent objects is the Single Responsibility Principle.
If you design your classes to have good fidelity to real-world objects, and you allocate responsibilities to those classes in a very focused way, you'll be happy with your object model. You'll be able to map it to a relational database with relatively few complexities.
Turns out, that when you look at things from a responsibility point of view, you find that 2NF and 3NF rules fit with sound responsibility assignment. Unique keys still matter. And derived data becomes the responsibility of a method function, not a persistent attribute.
The book "Design Patterns" is your next step.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612
But, you don't have to use an OO approach to everything. Don't be religious about it. If a more procedural approach feels more straitforward, then go with that. People new to OO tend to overdue it for a while.
I think Agile Software Development, Principles, Patterns, and Practices is quite good.
It provides a lot of in-depth disccusion of OO principles listed here:
The principles of Object Oriented Design and Dependency Management
SRP — The Single Responsibility Principle
OCP — The Open Closed Principle
LSP — The Liskov Substitution Principle
DIP — The Dependency Inversion Principle
ISP — The Interface Segregation Principle
REP — The Reuse Release Equivalency Principle
CCP — The Common Closure Principle
CRP — The Common Reuse Principle
ADP — The Acyclic Dependencies Principle
SDP — The Stable Dependencies Principle
SAP — The Stable Abstractions Principle
If you're used to building normalized databases, then Object Oriented design should come naturally to you. Your class structures will end up looking a lot like your data structure, with the obvious exception that association tables turn into lists and lookup tables turn into enums within your classes.
All together, I'd say you're a lot better off coming into OO design with a background in Relational Databases than you would be going the other direction.
If you want to really get to grips with O-O, go play with Smalltalk. ST is a pure OO language, and quite in-your-face about it. Once you get over the paradigm hump you've learned OO as you can't really do Smalltalk without it. This is how I first learned OO.
Check the results of this. Learn from each question.
I really liked Head First Design Patterns, which is very approachable, and the excellent Object oriented Design Heuristics by Arthur J. Riel
This site lists 101 title... design patterns, refactoring and other... Have a look at it.. It will be a good starting point...
Go for Object Thinking by David West. An interesting read..
You're from the dark side though.. as per the book;) Database thinking has been the curse of OO programmers all over. They're opposite ends of a spectrum. For instance
Database thinking values the data attribues over everything else.. normalization and creating types based on how they fit into the DB Schema OR the ER diagram.. OO thinking creates types based on behavior and collaboration and does not recognize the data attributes as all important.
Databases come from the scientific people who value formalization and method over everything else. OO comes from the people who use heuristics and rules of thumb and value individuality and social interaction over a hard and fast process.
The point being a COBOL programmer can write COBOL programs even after moving onto a OO Language. Check out any book like Thinking in Java for the first section which invariably details out the tenets of OO (Apprentice).. Follow it up with Object Thinking (journeyman) and in due time.. a master.
Model your objects by keeping real world objects in mind.
We are currently developing automation software for machines. One of those machines has two load ports for feeding it raw material, while all others have only one. In all modules so far, we had the information of the ports (current settings, lot number currently assigned to it etc) as members in the class representing the machine.
We decided to create a new class that holds the information of the ports, and add two LoadPort members to this MachineXY class. If we had thought about it before, we would have done the same for all those single port machines...
You should look at UML, which is an entire process given to OOD.
I'd recommend getting a book (or a couple), because the theory is quite large, most people pick and choose the techniques most appropriate for the project at hand.
Start reading about design patters, from say Martin Fowler. :)
They are the most practical use of OOP.
I am guess you mean OO in the database world.
Object-oriented databases which store objects never did really catch one so you are currently looking mapping objects to relational database. ORM or Object-relational mapping is the term used to describe the software that does this mapping. Ideally this gives you the best of both worlds where developers can internact with the objects and in the database everything is stored in relational tables where standard tuning can take place.
in DBA slang: object-oriented design is nothing else but properly normalized data behind safe operation interfaces, safe meaning, look at the operations, not the data directly