1) For abstract class a method must be declared as abstract. Abstract methods doesn’t have any implementation.
For interface all the methods by default are abstract methods only. So one cannot declare variables or concrete methods in interfaces.
2) The Abstract methods can declare with Access modifiers like public, internal, protected. When implementing in subclass these methods must be defined with the same (or a less restricted) visibility.
All methods declared in an interface must be public.
3)Abstract class can contain variables and concrete methods.Interfaces cannot contain variables and concrete methods except constants.
4)A class can Inherit only one Abstract class and Multiple inheritance is not possible for Abstract class.
A class can implement many interfaces and Multiple interface inheritance is possible.
Factory classes provide an interface for creating families of related objects. Factory classes are useful when the decision of which class to use must be done at run time and cannot be hard coded during development. Factory classes encapsulate the logic needed to decide which subclass to instantiate and so removes this decision from the application, delegating it to the factory.
The dimensional model is a specialized adaptation of the relational model used to represent data in data warehouses in a way that data can be easily summarized using OLAP queries. In the dimensional model, a database schema consists of a single large table of facts that are described using dimensions and measures. A dimension provides the context of a fact (such as who participated, when and where it happened, and its type) and is used in queries to group related facts together. Dimensions tend to be discrete and are often hierarchical; for example, the location might include the building, state, and country. A measure is a quantity describing the fact, such as revenue. It’s important that measures can be meaningfully aggregated–for example, the revenue from different locations can be added together.
Multivalue databases are ‘lumpy’ data, in that they can store exactly the same way as Relational Databases, but they also permit a level of depth which the relational model can only approximate using sub-tables. This is nearly identical to the way XML expresses data, where a given field/attribute can have multiple right answers at the same time. Multivalue can be thought of as a compressed form of XML.
The flat (or table) model consists of a single, two-dimensional array of data elements, where all members of a given column are assumed to be similar values, and all members of a row are assumed to be related to one another. For instance, columns for name and password that might be used as a part of a system security database. Each row would have the specific password associated with an individual user. Columns of the table often have a type associated with them, defining them as character data, date or time information, integers, or floating point numbers. This may not strictly qualify as a data model, as defined above.
An object-relational database is a database management system similar to a relational database, but with an object-oriented database model: objects, classes and inheritance are directly supported in database schemas and in the query language. In addition, just as with proper relational systems, it supports extension of the data model with custom data-types and methods.
An object-relational database can be said to provide a middle ground between relational databases and object-oriented databases . In object-relational databases, the approach is essentially that of relational databases: the data resides in the database and is manipulated collectively with queries in a query language; at the other extreme are OODBMSes in which the database is essentially a persistent object store for software written in an object-oriented programming language, with a programming API for storing and retrieving objects, and little or no specific support for querying.
In software engineering, an entity–relationship model (ER model for short) is an abstract and conceptual representation of data. Entity–relationship modeling is a database modeling method, used to produce a type of conceptual schema or semantic data model of a system, often a relational database, and its requirements in a top-down fashion.
The relational model for database management is a database model based on first-order predicate logic,
The purpose of the relational model is to provide a declarative method for specifying data and queries: users directly state what information the database contains and what information they want from it, and let the database management system software take care of describing data structures for storing the data and retrieval procedures for answering queries.
The network model is a database model conceived as a flexible way of representing objects and their relationships. Its distinguishing feature is that the schema, viewed as a graph in which object types are nodes and relationship types are arcs, is not restricted to being a hierarchy or lattice
A hierarchical database model is a data model in which the data is organized into a tree-like structure. The structure allows representing information using parent/child relationships: each parent can have many children, but each child has only one parent (also known as a 1-to-many relationship). All attributes of a specific record are listed under an entity type.
In a database an entity type is the equivalent of a table. Each individual record is represented as a row, and each attribute as a column. Entity types are related to each other using 1:N mappings, also known as one-to-many relationships. This model is recognized as the first database model created by IBM in the 1960s.