Discount Group) with the attributes Percentage, Name and a one-to-many relationship between your Business Customer entity and your Discount Group entity. At least you should create a entity for the discount membership (e.g. All attributes of all non abstract classes goes into a separate table ( Concrete Table Inheritance).īut honestly you should revise your ERM before.All attributes of each class goes into a separate table ( Class Table Inheritance).All attributes of the class hierarchy goes into one table ( Single Table Inheritance).To answer your question, you have three options to map your classes: In other words the membership options Silver, Gold and Diamond are no entities. GoldMember (CuID, ? DiscPerc, DiscAccrued,ĭiamondMember (CuID, ? DiscPerc, DiscAccrued,ĬuLocID is a Foreign Key to remove transitive dependencies relating to Post Code, City, Country (Location details that are stored in a different table - tblCuLoc)įirst of all, I think your ERM is bad design, because you should better use a role pattern instead of putting them into entities. SilverMember (CuID, ? DiscPerc, DiscAccrued, PrivateCustomer (CuID, CuFirstName, CuLastName, CuDOB, CompanyName, CuAddressLine1, CuAddressLine2, PhoneNumber, CuEmail, CuNotes, What is the best way to map the above into a Relational Schema? What will be differentiating attributes and generic attributes?Ĭurrently, I have come up with the following:Ĥ tables - PrivateCustomer(From Customer Superclass) and SilverMember, GoldMember and DiamondMember (From Business Superclass) Business customers have three membership options: Silver:10% Discount, Gold:25% Discount, Diamond:40% Discount. Instances of the subclass will inherit the attributes of only one of the superclasses, depending on the union that it belongs to.Here, Customer is the super-class, with Private and Business being the sub-classes with a disjoint mandatory participation, and Business customers is a super-class of Silver, Gold and Diamond sub-classes respectively again with a disjoint mandatory participationĪ quick explanation: Customers are divided into Business and Private. With specialization, an entity of the specialized type always also is an entity of the general type.Ī union (also known as a category) is a collection of superclasses that acts as a union between objects of different entity types. This is what makes generalization different from specialization. Important to note is that in this case a vehicle is either a car or a truck, but a car might not be a vehicle (in this model). The common attributes get transferred to the generalized type.Įxample: Cars and trucks can be generalized to vehicles. Generalization is used when you have a collection of entity-types that have some characteristic in common and you want to factor out this commonality into a seperate entity-type. In the disjoint case and when the specialized types partition the possible entities for the general type, we call that a partition.Įxample: Books can be specialized into monographies or anthologies. An entity of the specialized type is always also an entity of the general type.Often times you have multiple specialized types that may be disjoint or not, meaning an entity can be only one of the subtypes or can be an instance of multiple. This can include adding attributes or relationships to other entiti-types that are not present in the general type. Specialization is used when you want to add additional information to an existing entity-type. These two processes are used to incorporate more meaning into EER models. You can think of generalization as developing a diagram from the bottom up, whereas you can think of specialization as taking a top down approach to development. These additional concepts include generalization/specialization, union, inheritance, and subclass/superclass. All of the usual concepts contained in the E/R-model are also included in the EE/R model, along with additional concepts that cover more semantic information. The Extended Entity-Relationship Model is a more abstract and high-level model that extends the E/R model to include more types of relationships and attributes, and to more clearly express constraints.