ae ae FRIDEY jonal Data Modeling 7. DATA MODELING Basics modeling, oe lee i as entry attribute, cardinality of relationship, ee, do a quick recap on a few database terms such 7.2.1 Entity Entity is a common word for anything real or abstract ab i esl il ne categories sly cha tht hich we mat ste i ny ps match, crckee match, ete); locations (such as office campus, auditorium, mulplex theatre, ec), tangible things (suchas bale aE eat ecu Lather; Connors, Jennifer, fe enuld be ipsa ner eet ee Paes cabo He, 7.2.2 Attribute AE An attribute is a characteristic property of an entity. An entity could have multiple attributes. For ox for the “car” entity, attri f, model number, number of doors, right or left hand drive, engine number, diesel or petrol, et. 7 7.2.3 Cardinality of Relation: ‘This relationship defines the type of relationship between two participating entities. For example, one employee can work on only one project at any given point in time. One project, however, can have several employees working on 80, Tee caning ot seen ae “employee and project is “many to one”. Here is an example of a “one to one” cardinality. One person can sit on only one chair ar any point of time. Orie chair can accommodate only one person in a given point of time. So, this relationship has “one to one” ardinality. (To read more on en © An Introduc Tea With this understanding of a few sabes terms, let us proceed to understand data model. nS wresorDaraMODEL (data mode isa diagrammatic representation ofthe data and the relationship bensesn it lle entities, Although time consuming, the process of creating a data model is extremely important. assists in identifying evan repression gee ae B n, It helps in building a robust database/data and thus helps reduce possible errors inthe d warehouse, There are three types of data models * Conceptual Data Model. ~192+ ‘+ Logical Data Model, + Physical Data Model. : i It identifies the most important entities. 5 aye 2 ‘Ur itidentifies relationships between different entities e aed \ Tedogs not support the specification of attributes. (oe ar Pye ‘Ux It does not support the sp&cification of the primary key. Going back to the requirement specification of TenToTen Stores, model (Figure 7.1). In this case, the entities can be identified as let us design the conceptual data Category (to store the category details of products). SubCategory (to store the details of sub-categories that b Product (to store product details). PromotionOffer (to store various promotion offers introduced by the company to sell products) ProductOffer (to map the promotion offer to a product). Date (to keep track of the sale date and also to analyze sales in different time periods). : Territory (to store various territories where the stores are located). MarketType (co store details of various market setups, viz. “Hypermarkets & Supermarkets’ “Traditional Supermarket”, “Dollar Store”, and “Super Warehouse”). # OperatorType (to store the details of types of operator, viz. company-operated or franchise). # Outlet (to store the details of various stores distributed over various locations). # Sales (to store all the daily transactions made at various stores). long to different categories). There can be several other entities, but for the current scenario we restrict ourselves to the entities listed above. Let us now define the relationships that exist between the various entities listed above. © Outlet has a MarketType. * Outlet has an OperatorType. * Outlet belongs to a Territory. * SubCategory belongs to a Category. * Product belongs to a SubCategory. + ProductOffer is an instance of PromotionOffer for a Product. # Sales of a Product. A * Sales in a specific Date duration. * Sales from an Outlet. 7.3.2 Logical Data Model tienen (rhe logical data model is used to describe data in as much detail as possible. While descrbi g the dat < lescribing the data, ~ = : ractically no consideration is given to the physical implementation aspect. look at some features ct. Let us look 2 ons given to the physical implementation asp. at sé of a logical data model: \ © Itidentifics all entities and the relationships among them,FRIDI Cos ised eT ay + OCTOBER Ve aN Multidimensional Data Modeling, oars z bd j Date Market ‘Type pac % | { Sales >| Outlet >| Operator A ‘Type i I ‘Sub- Category ft 7] hemes Territory Product Promotion: Catenoy) Offer || Offers _-Figure 7.1 The conceptual data model for Ten ToTen Stores, Be wurde fishes Sh Oe aan . % It specifies the primary ef or each entity. ; ie Te specifies the foreign keys (keys identifying the relationship berween different entities). We? es if { S* Normalization of entities is performed at this stage. > Here is a quick recap of various normalization leves:|PK | Qperator1D | | Market_Name | | Promotiontype DiscountAmount Market 1D PromotionOfferIO_ Operator | | ComplimentaryProduct | | | Dateororier’xpiry | | PK.FK1 | ProductiD | PK,FK2 | PromotionOfferD [——*| FK1 | SubCategory!D i PK |= | openiatine MarketiD COperatori0” FKS | TeritoryiD 7 | ClosingTime ‘StoreOpenDate ‘TransactionDate FKa | StorelD FK3 | ProductiID. - ‘QuantityOrdered TotalAmeunt ProductiD ProductName Product Descripton DateOtProduction LastDateO‘Purchase CurrentinventoryLevel StandardCost ListPrice Discontinued DiscontinuedDate Figure 7.2 Logical data model for TenToTen Stores.Multidimensional Data Modeling, the (wo: Now that we understand foncepral and logical da ee model Jer us peform quick comparion berween ! \}. Allactributes for each entity are g fied in a conceptual data model, 24, Primary keys are presen in a logical dat : ! ) Pint aaa gical data model, whercas no primary key is present in a concep- 29) Ina logical data model, the relationships be iti i } Ste ips between entities are specified using primary keys fee com se @ conceptual data model, the relationships are reas! ee pecifying abuts It means in a concepral data model, we only know that swo ents ae ! related; we don't know which attributes are used for establishing the relationship between these wo entities. Sy) vod ; 1104 4 7.3.3 Physical Model i" G physical data model is a representation of how the model will be built in the database. A physical database model will exhibit all the table structures, including column names, columns data types, column constraints, primary key, foreign key, and the relationships between tables. Let us look oe features of a physical data model: ecified in a logical data model, whereas no attributes are speci- \}_ Specification of all tables and columns, ) Foreign keys are used to identify relationships benween tables. +) While logical data model i about normalization, physical daa mal may suppor, de-normal- ization based on user requirements. 3 Physical considerations (implementation concerns) may cause the physical data model to be quite different from the logical data model. & )Physical data model will be different for different RDBMS. For example, data type for a column ‘may be different for MySQL, DB2, Oracle, SQL Server, etc. The steps for designing a physical data model are as follows: © Convert entities into tables/relation. 3.© Convert relationships into foreign keys. Geg3 © Convert attributes into columns/fields. Let us look at the physical data model in the light of our TenToTen Stores case study, Having created the logical data model, now the physical model shall be created for the respective entities by adding the a men definition for the atributes. The detailed descriptions of the table are as shown below (we use MS SQL Server 2008 Database here): Category iProducrCategoryIDee wi\\\a 202 * (Continued) iStorelD INT Outlets GOurledD) Producti INT Product(iProductlD) iQuantityOrdered INT NOT NULL NOT NULL mToulAmount MONEY